SWTPcsbc 6809 was: Maybe a new kit coming soon

[vbriel]

Well, not soon, but in development. I hate to tell people it's coming and then run into a major design flaw or setback (aka AltairPC) but I'm working on a new platform. When I come up with an idea, it is something I want first. Sounds selfish, but like most of you builders I'm a fan of the way it used to be when you built a computer from a kit. So, I design something I want, then if other people want one, I do a run of them, pretty simple. If nobody wants one, no harm no foul.

The project I'm working on is a single board version of a system by SWTPc. If you google that, you will find Michael Holley's awesome site. When I was in high school in the early 80's we were fortunate enough to have about 5 TRS-80 model 1's, an apple IIplus and a SWTPc 6809 system with duel 8" floppy drives. The system ran Flex operating system and the computer science teacher was very strick on who got to use that machine. You actually had to read the manuals on the machine and the OS before you were allowed to use it. Well, after a studying the material for a few weeks I passed the test and was able to buy a $5 disk from my instructor! He made me go through all the pain in making my own system disk, then I was all set. The schools system had a SWTPc terminal that had a really cool 8" monitor built in and the keyboard had just a perfect feel to it. These systems are very rare to find and the terminals are almost imposible to get. I'f I ever had the chance to have one, I'd be really happy.

The design I'm attempting to make is going to cover the complete history of the SWTPc. The first systems used a 6800 and the later systems ran on the 6809 Motorola CPU's. The single board version of my platform will all you to plug in either a 6808 (6800 compatible CPU) or 6809, set some jumpers and power it up. Both monitor versions will be onboard and a complex memory management will handle the 2 different memory configurations the two systems used. A few years ago I made a 6809 prototype wirewrap boad minus a section of the memory management called the DAT (Dynamic Address Translator) which allows the system to reconfigure memory blocks in 4K segments in a virtual memory management format. This setup is required to run the monitor program for the 6809 unmodified. My wirewrap version excluded the DAT in the monitor for a simple design test. The Flex operating system uses the DAT and is required from what I've read.

Disk emulation will be done via a microcontroller and SD using FAT/FAT32 file system format. That is, if I can get the Propeller chip to work with the bus and read and write to the bus properly. This is the real hard part of this design. Doing the hardware work is finished but implimenting the firmware disk emulation will take some time to get working correctly.

My prototype boards are being made now and I should have them by the 10th and hopefully have the bios up and running shortly after that. From there, I'll be coding as hard as I can to get this system running. After things are working good, I'll see who wants one. I'm not promising anything right now, it is too early, but this would be another really cool rare computer system to learn from. The fun thing about these kits is, most of us never got to have Altair's or KIM-1's or Apple 1's so replicating them is the next best thing.

I'll try and post pics when I have something to show. In the meantime, feedback is aways welcome, good or bad.

Vince

[sje]

I was around at the time, and I recall seeing and trying a number of SWTPC machines.

If I recall correctly, the 6800 preceded the 6502, and the 6502 team was forced to change parts of their chip because of too great a similarity to these of the 6800.

The 6809 was the first eight bit processor to include a multiply instruction and this made array subscripting much faster. The chip was used in some Tandy products, and it was also the initial choice for the Macintosh before being replaced in the design by a 68000.

http://www.old-computers.com/museum/com ... st=1&c=567 SWTPC 6800

http://www.old-computers.com/museum/com ... st=1&c=562 SWTPC 6809

[vbriel]

It's been a while since I've designed a new platform (Micro-KIM) so I have butterfly's in my stomache. It's such a great feeling when you design new hardware and it works, and a horrible feeling when it doesn't. I love building kits, but I love designing boards even more. I think I'll start documenting my success/failures, tests and trails on this project as it develops.

Right now I'm waiting for the boards to be shipped. I've ordered all the parts to build a prototype (5 are coming) and I'm prototyping through http://www.4pcb.com also known as Advanced Circuits. I used them years ago for boards but the pricing on production runs are a little high. They have a $33 each deal but you have to order 4 boards. 5th board was a free special. With a board that is 7"X 5" this is better than the board house I use for production.

[wgoodf]

Always happy to have a new single board computer to play with, as you say, originals of most models are rare, broken and expensive.
Oh oh oh!

The Sinclair MK14, do that!

[vbriel]

The prototype is in. Here is a picture of the prototype unpopulated. I'm working on some flaws in the design (bummer) but that's what prototyping is for. After I get these bugs worked out, I'll start working on the disk controller firmware to the SD card.



Notice the logo on the board, that is something new for me. I've done custom fonts but never imported a logo until KFest. I'm still working on the 6809 section, then onto see if the 6800 (via a 6808) works. My issue in the 6800 is with a bug in the jumpers for memory addressing. I have to fix that with some rework wire.

[rwiker]

I have a feeling that I'll order one of these as soon as they are available...

[vbriel]

Ok, I've been battling with my logic analyzer for a while but I finally have it going and ran some tests with the SWTPcSBc. I ran a small program on the Propeller in Spin language to read the disk enable line. As soon as it registers it high, it pulses a signal on a pin. This is a test for me to see if I can capture the address and data bus signals. Well, the results of just toggling a pin with Spin code was horrible, 10ms which is way too slow. So, I had to rethink this project a little. I thought about going back to my favorite ATmega AVR's and make a disk controller that way, but I always kept coming back to the Propeller. The FAT32 driver is established, and it works. So, what I need to do was see if I could read the disk enable pin and toggle a response fast enough for the system. The way to do that is assembly with the Propeller. Not as easy as RISC based micros but still is a good solution. The logic analyzer is just a small test that took 2 days to get right. The pins are disk enable, my test output pin, R/W, E (like phase 0), and 4 address lines. The test was to see how quickly the pin is read and responds.




Ignore signal 9 and A4, they are pins not attached. It takes about 500ns to accept a trigger on the Disk E signal, then trigger itself on the Test read pin. For those studying 8 bit bus signals, look at how long we have to work with compared E at 1MHz. Being able to acknoledge Disk E fast is important becuase there is a HALT pin on the CPU if I need more time to do functions. Although, I don't think I will. Reading at the triggered line, the address it was reading was A0=1, A1=0, A2=1, A3=0. Enable is E01x so the A0-A3 decodes to 5 so it was hitting on E015. The program running was the monitor memory test program. I was testing addresses E010-E01F.

Next step is to try and place a response on the data bus during read and disk e. By the way, Disk Enable for now is only active during E so it is a short pulse.

More to come as I progress, slowly.

Vince

[vbriel]

This is becoming more like a blog, but here's where I'm working today. My goal for today is to stretch time on the bus. The MRDY signal is designed for slow memory devices. An external device can be considered a memory device and it looks the same to the system. So, what I'm doing today is just stretching The bus read time by pulling MRDY on the 6809 low for a couple ms. I've added the DATA bus signals and have dropped the test pin since MRDY will now be the signal of my triggering the scope.



Since I'm not sending any data on a read from the disk controller, the data bus is getting junk so ignore the D0-D8 for now. The signals to look at here are the DISK_E MRDY, E, and A0-A3. Notice when MRDY is pulled low upon DISK_E going high, I keep MRDY low for a few ms of time. The bus is held in an extended read state which will now give us a little more time to respond with data. Since this only happens when a read/write to the disk controller is requested, the system will not be slowed except for then. Since our disk controller should equal speeds of a disk drive, the system will operate at normal speeds.

For anybody studying electronics reading this, did you notice the slight difference in the DISK_E rising edge and the MRDY falling edge on the clock signals? This is a real world example of propagation delay not in a gate, but in the microcontroller response time. This is how much time passes before the Propeller chip detects a rising edge signal on the DISK_E line and pulls MRDY low. On zoom on the logic analyzer it is about 300ns. This is 1/3 of the normal clock cycle! There is a time limit on MRDY before memory corruption starts, so we don't want to hold MRDY low for too long.

Next step is to place data on the DATA bus and see if the system reads it.

[vbriel]

Here's a snapshot of what the system looks like running on the terminal. The SBUG monitor has been modified in this version to remove the DAT (and it may stay gone!)



The strange thing about the monitor, when you EXAMINE memory with the E command, the output does not put a space between the address and the 1st byte of data. So, the -000000 is actually address 0000 and value 00 for the first byte. FE is the 2nd byte, etc.

[vbriel]

Well, just a status update for anybody following. I suppose I should move this to a blog page Maybe soon. Anyways, a full day of code work and I'm getting there with a disk controller interface. So far, the Propeller acts like a 16 byte memory for the function registers. I can read and write to 16 address registers from address E010-E01F. I've even tested the addresses with the monitors built in extensive test procedure.

What's next:

Well, I consider this the raw engine for the disk controller. Now I can focus on doing disk controller commands like read and write to a disk image on the SD card. Think of a disk controller as a memory device. You send a byte command to it and get a byte value back. There's more to it than that but it is progressing nicely. I won't be happy until I have a working disk system going.

Vince

[danwerner]

Hey Vince,

I did a FLEX port for the N8VEM project's 6800 host processor, and quite a lot of that code might be helpful on this project. All of the code is on the N8VEM wiki site, and I am happy to help if you need any explaination of the custom disk/console IO code that I wrote for that port. Looking forward to the new kit!!

Dan Werner

[vbriel]

Ok, it's been a while since I've had time to play, things got busy and the Maker Faire took up a lot of my time getting ready.

So, here's were we are sitting. At last update I had created a 16 byte register memory on the Propeller chip using direct bus access and had that working...or so I thought. I ran into some SD card reading issues and then had to stop working on it. Well, today I had time and worked on some bugs in my code and got the SWTPCsbc able to read from a file stored on the SD card. GREAT! Except, when I stored data in the propeller's registers I created to use as disk controller registers, the data was corrupting. The Propeller is a 3.3V device and I'm connecting it to 5 volt TTL circuits via 1K inline resistors to the data bus. This created an issue when reading the data out onto the bus. So, I've since removed the inline resistors and it appears to be working. Next I'll start writing the code to emulate the SWTPC disk controller and see how that goes. I'll start with the raw sector read/write and go from there.

This project is on the move again. On a side note, I'm considering just making this a single CPU board. The 6809 would be the ideal choice and 6800 software can be compiled to run on the 6809 (as far as I'm aware) so it would simplify the project greatly to just have it running one CPU type.

Vince

[danwerner]

The two chips are "assembly source code" compatible, so you can re-assemble to 6809. There is also a 6809 specific version of FLEX, so no problems there either.

Dan

[vbriel]

Yes, thank you for confirming what I thought was true about recompiling 6800 code into the 6809. Strange how they didn't keep the opcode's the same for backward compatibility. Things are moving along, slow victories! Today I set up part of the read sector process so I can start sending data without data loss. The way the 6809 software reads a sector, it sends a command, waits for it to be clear, then reads a byte. It keeps checking the com register to see if the disk controller is ready, if bit 1 is set, it is not ready. I can now control when it is ready by setting this bit after a read to the data register of the disk controller. Next I'll complete the process for reading a sector into memory and test it out. After that, I'll work on writing a sector to disk image.

The beta version of the disk controller will have only one drive. There is no reason why I can't have 2 files on the SD card labeled disk0 and disk1 and have 2 or more floppies. I'll have to see what the specs of the controller are for how many drives it can control.

The reason things are progressing slowly is the Propellers assembly language. It is memory address oriented instead of register oriented. So, I keep falling into the trap where I think I'm reading a register, when I'm actually just reading a pointer to a memory location. My brain hurts right now, I'm going to decompress and watch some sci-fi on TV.

Funny, I have a wire-wrap prototype and now a circuit board prototype I can work with. The circuit board prototype has an issue starting up the 6850 serial port and I have to reset, cycle power sometimes, whereas the same circuit on the wire-wrap doesn't have that problem. It means I have to cycle power a few times to get it up, so it is an init thing. I'll get it fixed by the next board layout.

[vbriel]

I got to the point where I'm ready to try and read a sector into RAM. I tried running the monitors boot option for the mini disk 5.25" option. It sets the drive number just fine, it restores to track 00 without error and the command to start reading a sector is recieved (command register gets 8C). After that it does checks to see if the controller is busy and it gets stuck there. After a while, it just goes back to the prompt. I"ll have to pull the ready line and see where the exactly it is getting stuck (it's one of two places) so I can see if I can fix it. The nuclear option would be to write my own sector read/write code for the 6809 and build the flex core setup with this new code. I really don't want to have to do that, so I'm going to work on this with thought of using the completely original operating system code. The nice thing is that if I do have to rewrite the code, there is a Flex manual that is written to help you do this. This manual is the Flex adaptation guide, if anybody wants to see where I'm at in this project.

Vince