An evolving 68000 SBC

[Bill Shen]

This is a design with evolving goals.  The original motivation was an inexpensive 68000 tester for couple dozens of unknown ceramic/gold DIP64 68000.  They have fairly fragile leads that’s hard to line up correctly in the 64-pin socket.  I want a tester with ZIF 68000 socket and I want the tester to be simple and cheap, just enough functions to serially load & run test programs.  CPLD can save cost, but it needs to be the smaller, lower pin count one for best price and availability.  The concept is to combine ROM, serial function, and decoding logic in a 44-pin CPLD so the tester is consisted of  a CPLD and two cheap 128Kx8 RAM, that’s all.  It operates by boot strapping from the small CPLD ROM to load and run 512 bytes of test program via the serial port and report the test results via serial port.  Trying to squeeze ROM, serial, and decode logic was rather challenging, but it got done.

Moving the goal post, adding 512k RAM and CF interface:  512K RAM is pin-compatible with 128K RAM so it is a no-brainer; CF interface opens the possibility of bootstrapping from CF disk and load/execute test programs automatically.  CF interface can be problematic for 68000 because of timing differences and noisy 16-bit interface.  The interface may only work with limited brands of CF disk, so I’ll need to do some testing to qualify working CF disks.  I also need to work out a process to produce working CF image.

More goal post moves, an optional dual serial port:  the CPLD serial port has limited functionality and only single serial channel.  MC68681 is dual serial channels with a number of discrete input and output I/O, a more versatile device.  It obviously adds more cost, but CPLD may become the smaller and cheaper ($3) ATF1502 class device resulting in more versatile 68000 SBC.  I’ve got space on 100mmX100mm PCB, so why not.  This is the PCB sent to JLCPCB.  To be continued…

Bill

[Bill Shen]

This is the implementation of the original  simple 68000 tester; it consisted of two 128KB RAM and a 64-macrocell CPLD (ATF1504 or EPM7065S), that’s it.  CPLD  has a small (64bytes) ROM, simple serial port and glue logic including a RAM/ROM page register.  After a reset 68000 boots from CPLD ROM and wait for incoming binary data from the serial port.  Serial input are stored in RAM immediate after the end of ROM; once 256 bytes of program are received, RAM/ROM page register is flipped to continue program execution in RAM. 

This setup is sufficient to load test programs to sell-test a 68000.  The screen capture shows a S-record loader was first loaded into RAM; then the S-record loader loads and run the memory diagnostic.

The trouble with this setup is programs must be serially loaded for every reset.  We will add a CF boot capability next.

Bill

[Tom Storey]

You could try buffering the CF card to the data bus. I've always used buffers in my designs and don't have too much to report in terms of incompatability. There has only been one CF card which I wasnt able to work with, but a variety of SanDisk, Cisco whatevers, and some other random cards all seemed to work fine. At the very least it would contain any noisy signals to a small stretch of PCB traces rather than all throughout the system.

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/retro-comp/8e523f1c-1ad5-46d0-a69f-375195f83b88n%40googlegroups.com.

[Bill Shen]

I’ll keep that in mind.  Although my own experiences with CF interface are no buffers needed.  I did have an overclock experiment with W65C02 that was able to run 36Mhz without CF, but with CF inserted, its max speed dropped down to 32Mhz.  At the time a person also suggested a data buffer, but I haven’t got around to try it.

Bill

[Bill Shen]

This is a 68000 tester with ZIF socket, 2x512KB RAM, and CF bootstrap testing one of the ceramic/gold 68000 I have.  Moving from serial bootstrap to CF bootstrap involves several steps.  First is changing the ROM in CPLD to monitor CF Busy status and read the default sector (Master Boot Record) into RAM.  Second is switching off ROM and executing the program loaded into RAM, and third, load additional software into RAM.  The screen capture shows my own monitor along with TUTOR v1.3 are loaded into RAM in third step.

The CF interface is 16-bit wide and source terminated with 100 ohm resistors on all data lines.  It also has 100ohm/100pF filter network on the CF read strobe to further control the ground bounce.  I also accumulated and displayed checksum to monitor the integrity of CF transfer.  I learned to use srec_cat.exe from Wayne Warthen and built the CF image composed of MBR bootloader, TUTOR, and my own monitor.  CF bootstrap is fast and convenient; it seems reliable with several different brands of CF disks.

One problem is the ZIF socket won’t stay closed reliably; the level popped up easily.  Fortunately it only took a few seconds to test a 68000.  I’ve managed to test all ceramic/gold 68000 with the flawed ZIF.

Bill

[7alken]

hi Bill, I am watching this since start and for some quite long time thinking here how to do cheaply also something with those BGA dragonballs - do you want to mix something about it here or better start new thread? if you have some more design files for this your board (complete boot data in cpld?), I am interested to copy something, M68 unknown still to me; probably soon will do finally some CPLD things, as all this inspired me also to do some RCBus adapter for these my 7xmod/7xmem and just today I did some draft how it may look (was unable to figure it out for long time, but-today something sparked...)) it may be also 100mm RCBus board, quite passive, only with dual epm3128 (5V tolerant) and my various smaller connectors - as it seems to be glued mostly by cpld then also that dragonball may be sooner - I till now solved 16bit sram for EZ (no UDS/LDS on just this one) with some appnote, but in fact, good to have it in cpld also - as ultra weird option I considered some old async MCP (nor flash + (1T dram) utsram/psram, samsung and spansion, slow 70ns but enough for EZ ...  in fact, only 2 tiny chips with 8bit data bus are required, sadly the amd/fujitsu CFI flash is more complex to program in system (was peeking also into kanpapa DragonOne example, sure, just openede here - as I am expecting wild BGA experiments, I need cheap tiny multilayer PCBs as there will be some waste probably ))
Petr 

[Bill Shen]

The motivation was a simple board solving the problem of 16-bit ROM and more complicated 68000 glue logic.  I thought it as a throw-away board just for testing the big DIP64 68000 then reuse the parts for other designs.  Along the way I realized the design approach is a solution solving the general problem of 16-bit CPU RC2014 add-on boards on 50x100mm form factor, so I will try designing 68k, Z8000, and NS32xxx CPU boards for RC2014.

The remaining hardware project for this board is adding 68681 DUART; there are several software project such as EhBasic, CP/M 68K and EmuTOS before I wrap up this board.

Dragonball is a 3.3V device and fairly easy to interface with, so I don’t think a CPLD is even necessary.

Bill

[Bill Shen]

The 68000 tester has evolved from the bare bones serial-bootstrap configuration to CF-bootstrap one-megabyte RAM configuration and now to the external DUART serial port 68000 SBC.  The operation principle is still same as the CF bootstrap configuration, i.e., 68000 executes the ROM inside CPLD after reset which loads/executes the program in CF's Master Boot Record, which, in turn, loads monitor and TUTOR into RAM.  The monitor and TUTOR have been modified to use the external MC68681 serial port.  

 

There are several benefits associated with the external MC68681:

1.  MC68681 has dual serial channels as well as a number of discrete input and output.  It also has timers and robust interrupt capabilities, so it is a significantly more versatile IO device.

2.  MC68681 has independent baud clock so it is decoupled from 68000's system clock.  This means the tester can have different system clock to check out faster or slower 68000.  In fact, I did an overclock test and found the board with 10MHz 68HC000 is capable of 20MHz operation.

3.  Without the embedded serial function, simpler and cheaper CPLD can be used.  In this case a 32-macrocell CPLD, EPM7032S, is used which is equivalent to ATF1502.

 

The MC68681 configuration has several design mistakes around the interrupt and DTACK functions so requires some modifications.

They are fairly minor and easily fixed with a new board revision.

 

I'm done with hardware description of the 68K tester.  I'll spend some time porting EhBasic, CP/M68K, and EmuTOS to it.

 

An interesting follow-up is repackaging the design for the original 40-pin RC2014 bus.  Instead of a dedicated 16-bit RAM board, the RAM function is moved to 68000 CPU board while the ROM function is embedded in on-board CPLD.  The CPLD also converts the 68000 bus signals to be compatible with RC2014 bus signals.  After reset, CPLD ROM copies 68000 codes either from RC2014 CF disk or RC2014 ROM and store them in the on-board 16-bit 68000 RAM, then the ROM is paged out and 68000 executes the freshly copied codes.  Such 16-bit CPU board can fit the standard 50x100mm RC2014 form factor with PLCC 68000 and SOJ RAM while retaining the simpler 40-pin RC2014 bus. 

[Bill Shen]

Porting EhBasic to 68000 tester is simple because EhBasic for 68k used Trap 15 services for I/O functions, the same Trap services in the 68000 tester, so I only need to adjust the memory base then it works.  Photo shows EhBasic loaded into memory and executed the Mandelbrot benchmark.

Porting CP/M 68K is more complicated; a new BIOS is needed and CF disk needed several essential CP/M 68K programs (init, pip, Kermit) to initiate new CF and upload files to the new CF.  The memory layout is BDOS, CCP located at 0x15000, BIOS located at 0x1B000, TPA from 0x20000 to 0xC0000 (640k ought to be enough for anyone!), and RAM disk from 0xC0000 to 0xFFF00.  The essential programs are loaded into RAM disk and used to initiate new CF disks.  The approach is loading BDOS, CCP, BIOS and essential programs as S Records during software development.  Once they are working, they will be installed in RAM during bootstrap.

I used Easy68K simulator (Sim68K) to debug the software and created the image of RAM disk containing INIT.68K, PIP.68K, STAT.68K, and GKERMIT.68K.  Sim68K used the same Trap services for I/O which made program debugging easier.  Photo shows directory of CF drive A that had essential programs INIT.68K, PIP.68K, STAT.68K, GKERMIT.68K and 68K BASIC compiler (CB68.68K, CB68.L68,  LINK68K, ASCIIART.BAS) that were uploaded via GKERMIT.  ASCIIART.BAS was compiled and ran. 

Bill

[7alken]

cute :-) ... dragonballs are stalling the bus at least once a week ... thing is, my baby is not only for them;  btw, I digged my old mails and was surprised by bandwidth back then, cant remember what nmi sent everyhting in error state to weird silent hell .... ))
P.