CB030, a 68030 SBC

[Bill Shen]

MC68030 was introduced in 1987 but probably not considered retro since it really was a modern 32-bit processor with MMU.  Anyway, I thought I'll mention a 68030 SBC under development, CB030.  'CB' refers to Cecil B., an enthusiastic 680x0 user who has motivated me to update my 3-year old Tiny030.   I'm in the midst of porting CP/M68K to it, but it really should have a more modern operating system which is beyond my capability.   Hopefully some software guru may take an interest in CB030.  The link to CB030 is here for anyone interested.

https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:cb030
  Bill

[Steve Crompton]

Hello Bill,

I will be following your progress with interest as I have my 68HC000 computer which I want to get CP/M68K running on too, I have just finished my larger memory board (2MB RAM + 256K ROM) with RAM at 0x000000 except at boot, next is some form of storage - I guess I should add an IDE interface but as yet I am unsure how to do this, I need to see whats involved as I have no experience of adding such an interface to ANYcomputer. can you suggest any good reading on the subject that is easy to digest - I don't have time to read 400+ pages of documentation on IDE spec. so anything that can fast track me to whats needed would be good.

[Bill Shen]

Steve,
If you have a decent size ROM (1 meg), you can store CP/M68K system files in ROM drive, call it drive A.  You can also set aside 1.5 meg of RAM for RAM drive, drive B.  This way you can get CP/M68K running without external mass storage.  The BIOS software for RAM and ROM drives are simple, so it is much easier to port CP/M68K this way.  This is what I did with MPU302
https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:mpu302

Even with CF drive, having a ROM drive preloaded with some CP/M68K software is useful because you can use the software on ROM drive to format the CF drive and transfer files from PC to CF disk.  You probably will wind up read the CF spec because there are two major issues you'll have to work through:

First is access timing to CF disk.  With Z80, the chip select is asserted before read/write strobes and many CF interface designs simply decode the I/O addresses to generate CF chip select and use the Z80's read/write strobe as CF's read/write strobe.  This violates the CF timing, but works for some brand of CF disks (especially CISCO brand) so the problem is manageable.  68K timing is such that you absolute must insert a wait from CF chip select to CF read or write strobe, no way around it.  So you'll need logic to re-generate CF read/write strobes from 68K's R/W signal.

Second is signal termination of CF interface.  With 68K, you may want to interface to the CF disk in its native 16-bit mode.  You need to be careful with ground bounce as the modern CF disks have significant drive capability that can cause significant noise on the system ground to mess up CF access.  The noise is data pattern dependent so you may encounter puzzling intermittent errors that's hard to troubleshoot.  I use 100 ohm serial termination on the data lines and control lines and bring extra ground traces to the CF interface.

It is important to test your CF interface with many different brands of CF disks.  You will find out quickly that some brands work well, others will fail immediately or intermittently.  Don't blame the CF disks, if you can format/read/write a CF disk with your PC but can't access it reliably with your 68K, the problem is NOT the CF disk.
  Bill

[Tom Szolyga]

Hi Bill,

Great design!  I like the idea of upgrade RAM to 64MB.  Sign me up!  I want to buy the board with the CPLD mounted and add my own components.

Tom

[Steve Crompton]

Hello Bill,

Thanks for your reply, that is most useful. I quite like the idea of leaving out the CF for now and getting CP/M-68K running from ROM first. My approach is always "baby steps" - that way when it doesn't work there is less to worry about and debug. My new memory board gives me 2MB RAM + 2x 256KB ROM (as it stands you can choose the upper or lower half of an EPROM with a jumper) so when you say that I would need "1meg" ROM I assume you mean 1M x 8 bits or in my case 512K x 16 for the 68HC000 my system is based on so my current board would not do as it only has 512KB ROM (256K x 16) ?

I could always look at building up another PCB with bodge wires and fit pin compatible ROM's in the 4 RAM sockets I guess - probably need minimum hacking to get a 512K x 16 ROM board

On Thursday, 16 January 2020 16:48:47 UTC, Bill Shen wrote:

[Bill Shen]

Tom,
Thanks for your interest in CB030.  I am successful in porting CP/M68K to it, but also discovered a few design mistakes which will need a new board revision.  I plan to go to 4-layer pcb for next revision of CB030.  It is still affordable, about $30 for 10pcs 4"x4" boards.  My goal is to be able to provide pc board with SMT devices including EPM7128S assembled and programmed for $15.  Of course all design information will be released so you can make your own boards or modify the design as you see fit.
  Bill

[Bill Shen]

Steve,
"Baby steps" are good!

You don't absolutely need 1 meg byte of ROM (1Mx8).  CB030 has 512Kx8 of EPROM; CP/M68k BIOS/CCP/BDOS is 45K, EhBasic is 20K, monitor is 16K and reserving 40K for utilities, so there are about 384K remaining.  Here are what I currently have in 384K byte of EPROM:

A>stat *.*

 DRIVE A:                         USER :  0
 RECS  BYTES FCBS ATTRIBUTES      NAME
  154    20K    2 DIR RW        A:AR68    .68K
  427    54K    4 DIR RW        A:AS68    .68K
   49     8K    1 DIR RW        A:AS68SYMB.DAT
   14     2K    1 DIR RW        A:DDT     .68K
  431    54K    4 DIR RW        A:DDT68000.68K
  111    14K    1 DIR RW        A:DUMP    .68K
  131    18K    2 DIR RW        A:ED      .68K
  125    16K    1 DIR RW        A:FIND    .68K
  351    44K    3 DIR RW        A:GKERMIT .68K
    6     2K    1 DIR RW        A:INIT    .68K
  296    38K    3 DIR RW        A:LINK68  .68K
  183    24K    2 DIR RW        A:LO68    .68K
  277    36K    3 DIR RW        A:ME      .68K
  114    16K    1 DIR RW        A:MORE    .68K
   84    12K    1 DIR RW        A:PIP     .68K
  104    14K    1 DIR RW        A:STAT    .68K
----------------------------------------------
TOTAL:  372K   31
A: RW, FREE SPACE:         4K
A>

Enough to copy/edit files, assemble 68K programs, debug program, and transfer files to/from PC, but not enough room for C and BASIC compilers.  You can transfer additional files to RAM disk, but that's painful unless you have battery backed RAM.

  Bill

[Steve Crompton]

Hi Bill

Ok, so the hardware I have will probably suffice for now. I have just been looking at your "Port CP/M-68K to MPU302, part 1" where you get CP/M-68K running in Easy68K. I use Easy68K and so thought it might be a worthwhile exercise following what you did initially and try and get it working in simulation first ... 

Is your Easy68K BIOS code shared in that article somewhere Bill?

I assume your Easy68K BIOS uses the Trap 14 for console I/O under simulation and then you modify it for the hardware later? 

On Thursday, 16 January 2020 16:48:47 UTC, Bill Shen wrote:

[Bob Dunlop]

Think I can claim being the first person to lay my hands on a 68020 in the UK.  Was working for a small company developing 68010 based Xenix boxes and we had put a request in for one chip on the off chance.  Best we can guess when one chip came up for demo they put it on the system and it skipped the likes of Intel, IBM UK, EMI as it couldn't fill their orders for multiple chips, but here was an order for one chip it could fill.

Remember looking at the parcel and going Oh Shit!  We'd got a shim board designed and in prototype production before the marketing droids caught up.  We gave up the chip with good grace in exchange for a few favours.  Silly thing is they could have waved anything under the nose of the press and no one would have been any the wiser.

[Bill Shen]

Steve,
I uploaded a file "cpm68k_4_sim68k.zip" that contains the 4 S-record required to run the Sim68K.  I attached the file here as well.  This is the instruction for running it:

EASy68K simulation files.  Load MPUBIOS.S68 in Sim68K first, then use the 'File'->'Open Data' sub-menu to load CPM15000.s68, SIMDSKA.s68, SIMDSKB.s68.  Then set the PC register to 15000 and run (F9).  You'll see the CP/M prompt at Sim68K I/O console.

MPUBIOS uses Trap #15 services to work with Sim68K.  I also implemented Trap #15 services on the actual MPU302 hardware so the code that worked in simulation also worked in actual hardware.
  Bill

[Bill Shen]

Oops, forgot to attach the file.  Here it is

[Steve Crompton]

Hello Bill

Thanks for coming back to me. I have unzipped the files and followed your instructions but it does not work for me - I get trap exception occurred at 17378

What am I missing? - any idea? - I haven't really used the Simulator, I just make use of the Assembler Easy68K so its all new to me

Any help appreciated

Thanks Bill

On Thursday, 16 January 2020 16:48:47 UTC, Bill Shen wrote:

[Bill Shen]

Steve,
That's easily fixed.  Drop down the 'Options' menu and click on 'Enable Exceptions' then you are ready to run.
  Bill

[Steve Crompton]

Ah simple fix - guessed it was me missing a trick - working now :-)

Thank you so much Bill

Probably wont get to do much with it this w/e now as work comes first - however now I have something running in simulator at least I can have a play with CP/M-68K over the coming days

I feel I have made a big leap forward towards my goal of getting an OS running on my hardware, great tip Bill not to bother with CF interface for now

Speak again soon Bill

Best Regards

Steve

BTW you in the UK Bill ?

 

On Thursday, 16 January 2020 16:48:47 UTC, Bill Shen wrote:

[Bill Shen]

Got to make money so you can play!  I live in Albuquerque, New Mexico USA--over 40 years now.
  Bill

[Steve Crompton]

Wow - its amazing how the power of the internet connects people with similar interests irrespective of distance

Have to work yes .... but the older I get the less I want to work and the more I want to play :-)

On Thursday, 16 January 2020 16:48:47 UTC, Bill Shen wrote:

[Steve Crompton]

Hi Bill,

When you run from 15000 the A> appears immediately and all seems good

I was thinking today though - no software banner indicating CP/M 68K and no version info displayed either at startup

Is this something you removed Bill or just simply isn't there in the code ?

Maybe this is normally shown from some sort of CP/M loader program ?

I know its cosmetic but just thought it strange - any comments / thoughts on this point

Best Regards

Steve

On Thursday, 16 January 2020 16:48:47 UTC, Bill Shen wrote:

[Marten Feldtmann]

That is pretty interesting ... and I would buy one. Some "wishes":

* use a full 2x40 extension adapter like the ones from Steve and put all signals on that needed for a 32Bit system. Just leave the +5V and GND and changed all the signals as you may wish. An extension would be very important.

* Please consider enabling DMA for the extension board (so do not forget DMA signals) and the interrupt possibilities.

* Perhaps consider address selection signals for IO (that means - define e.g. 16 areas in the memory space for IO extensions ... so a 4 to 16 decoder can be used for up to 16 extension cards).

 Actually I am happy to see these M68K systems ... a new MC68K system would be the target of my retro work ... but the base PCB (with CPU, memories) are pretty difficult for me, but I assume, that an extension card would be possible for me to do.

Marten

[Bill Shen]

Steve,

When CP/M is booting up through the CP/M loader, a standard Digital Research banner will display.  In simulation the CCP and BDOS are already loaded into memory as well as the RAM disks (disk A and disk B) so it bypasses the CP/M loader.  For better or worse, I also use the same method to load CCP/BDOS in real hardware; another word, the image of CCP and BDOS are stored in flash somewhere and when I invoke CP/M68K, it copies the flash image into RAM location and jump into it.  Another word, I'm not loading CP/M68K the traditional way which first loads the CP/M loader from system track that, in turn, loads the CP/M system file.  This means I also skip displaying the Digital Research banner at start up.  To work around that, I do insert a sign-on message in BIOS that displays the Digital Research banner as well as a software version number of BIOS.  That is not in the BIOS you have, which is an early version.  I've done enough CP/M BIOS that I don't use simulator anymore.

  Bill

[Bill Shen]

Marten,

Since the memory can be as large as 128meg, I didn't see the need for more memory, so the expansion is for I/O devices which are mostly 8-bit devices and use relatively few address lines.  The pin assignment for the 40-pin connector is similar to RC2014 except the M1, MREQ, IORQ, RD, and WR have different meanings.  M1 is interrupt acknowledge, MREQ is one I/O device enable  while IORQ is another I/O device enable, RD is DTACK0 and WR is 680x0 R/W.  I/O are memory mapped in 680x0 world.

DMA is a tough one, especially 32-bit address/data bus with complex encoding of function codes & size code.  The signals mushroom to large number and most designers find DMA function difficult to use in practice.  It is definitely a luxury feature, not for an economy model like CB030.

At 24MHz and no data/address buffering, the expansion bus can only have limited number of boards.  I would think 4 expansion boards is all it can reasonably support.

I think of CB030 as a "throw away" model with a cheap $15 base board.  The end users can check out their hardware and practice 680x0 software on the economy model and then move on to better, full feature model.

  Bill

[Steve Crompton]

Hi Bill,

I did wonder if it might be the some bootstrap loader responsible for displaying the banner and you have kindly just confirmed that - cheers

What version of CP/M-68K do I have here Bill in the ZIP ? - is it V1.3 ?

On Thursday, 16 January 2020 16:48:47 UTC, Bill Shen wrote:

[Bill Shen]

Steve,
Yes, it is CP/M68K v1.3.  I'm told that it fixed some significant bugs in v1.2.  However, the v1.3 C compiler floating point library does not work.  I believe the library is corrupted, but I've never managed to find a working floating point library.  The C is also an early dialect of C, before K&R.  I first learned about C in 1978, so I actually like the early dialect without all the boilerplate.
  Bill

[Steve Crompton]

No problem Bill thanks for confirming its V1.3

I don't think CP/M-68K floating point C library is gonna be a bother to me, I would prefer to do my development on a PC anyway :-) I am happy with Easy68K at the minute to generate code for ROM's on my hardware - latter I would like a PC cross assembler and C - Compiler if one exists (I'm sure it must somewhere) but I can live with what I have for now.

So much going on and not enough time to play but will be putting effort into progressing my 68HC000 system - need hardware BIOS changes now so that CP/M-68K can run on it.

I'm going to have a read through your MPU302 documentation to figure out how you download stuff via CP/M OS to the target - presumably there's a file transfer util on one of the CP/M drives for this purpose or maybe you still use a command built in the ROM monitor outside of CP/M

Anyway I think I will start a new topic if I have any questions if thats ok?, and sorry for polluting your thread about CB030 with this - we are more than a bit off topic now with CP/M

Thanks for help Bill - much appreciated

Just a comment on your CB030 project Bill, I purchased a couple of 68030RC-33 parts off ebay (for future project post CP/M OS on 68HC000 system) and believe they are genuine parts - seems to be a lot of fakes floating around and not sure how well they work, but also finding the PGA sockets I found difficult, so I wonder how others will get on sourcing these two items at reasonable money - do you have a good source for cheap 68030's and the PGA sockets or do you have a large supply in your own personal inventory ?

On Thursday, 16 January 2020 16:48:47 UTC, Bill Shen wrote:

[Bill Shen]

Steve,
Yes, do start a new topic on porting CP/M68K to new 680x0 hardware and I'll be happy to continue the conversation there.

There are lots of fake IC in general on eBay.  It doesn't mean it won't work, in most cases they'll work just fine--they were used parts with bent legs, proprietary markings or cosmetic defects.  Such parts are likely mistreated during the removal process so may have latent defects.  CMOS parts with higher than normal idle current is a sure sign of latent defects due to static discharge, yet it may continue to work for its normal life with the higher idle current, OR just die with next minor static discharge event.

68030 socket is hard to find and expensive when you do find it.  Search for '68030 socket' on eBay and you'll find 2pcs for $12 but shipping is $7 more.  You can find 68030 from $10 to $15, so I just solder mine directly and not worrying about socket.  I do have a private cache of 68030, but at this rate it'll run out soon.
  Bill

[Marten Feldtmann]

mouser.com has some (7) available. 68030 from utsource (Pga) seem to be around $11. Better solution would be the MC68EC030 (without MMU) or MC68EC020 (limited to 16MB) for around $4 with QFP socket (whoever can soldier this).

Marten

[Alan Cox]

On Sunday, 19 January 2020 21:15:00 UTC, Steve Crompton wrote:

Hi Bill,

I did wonder if it might be the some bootstrap loader responsible for displaying the banner

It would be nice if the firmware first loaded physical sector 0 of the CF card and if it started with the right magic number jumped to the address after. That makes it a lot easier to be able to boot other things (TOS, Unix, whatever) and still get straight into CP/M (or basic or similar).

Alan

[Mark T]

Maybe a checksum could be the magic number. That would also give some indication that it hasn’t been corrupted.

Mark

[Bill Shen]

You can find common 13x13 PGA socket fairly easily and cheaply on eBay.  It is not fully compatible with 68030 because the inside 4 pins of the 68030 PGA are VCC and the common 13x13 socket only has 1 inside pin.  Since all the 4 pins are VCC and there are plenty of VCC on other pins of the 68030 PGA, I got this bright idea that I can just ignore the 3 missing VCC.  So I built up another board using the common 13x13 socket instead of the dedicated 68030 socket, and guess what? It doesn't work!

It turns out there are multiple VCC supplies for 68030, dedicated to address buffers, data buffers, control buffers, and internal logic.  If I've just read the datasheet first, I'd found that out.  All is not lost, I can wire in VCC to the missing corner sockets and it all work again.

Lesson learned here is buy the 68030 sockets.
  Bill

[Steve Crompton]

128 Pin PGA on EBay don't seem that easy to pick-up - I have a few for my project now but I browsed EBay for weeks until some were available

[Bill Shen]

I ordered a few from this vendor.  I hope they are low-insertion force sockets.  Fortunately the 68030 has plenty of room around it to insert a prying tool.
https://www.ebay.com/itm/2pcs-Brand-New-128pins-PGA-Socket-13x13-for-68030/250474705812

[Mark T]

Maybe its possible to make one. Remove the pins from a turned pin ic socket or socket strip. Then measure the diameter and have a pcb drilled with a matrix of correct sized holes for the pins to press fit. If a complete matrix was drilled it might also work for some other devices. Black pcb should look quite good, not sure if its best to use plated or non plated holes, non plated might give a better grip on the pins.

Mark

[Bill Shen]

The plastic socket housing is actually not required.  If I have a bunch of individual socket pins, I can plug them individually into a 68030 PGA, line them up over the pc board (this part may be tricky) and solder them.  The end result is a matrix of free standing sockets held in place by solder.  The 68030 PGA serves as a template to line up individual socket pins.
  Bill

[Mark T]

Not sure if the socket pins would stay straight, they tend to pivot at the contact point. Maybe if the pcb mounting holes were close fitting.

Mark

[Greg Holdren]

Using individual machine pins was my suggestion too. To keep the added pins straight just use a machined SIP sock and plug it in on the top where the 030 would be and hang it over into the single pin and solder the single pin in place.

Greg

[Colin MacArthur]

Being "OLD" and "living in the middle of nowhere", in the past I have had to find "alternative  parts".

I just use Wire Wrap Perfboard & Machine Pins.

I don't have any of the original homed examples BUT here are 3 examples that show what I am talking about...

You just cut the perfboard to size & insert the pin.

CM

[Colin MacArthur]

FYI

The "Wire Wrap Perfboard" would also make a great "Drill Template"

CM

[Bill Shen]

This is a 68020/68881 SBC I designed for a community college class 20 years ago.  I just removed the 68881 to show the socket underneath which is really just an array of free-standing machined pin sockets.  Low-insertion-force sockets are preferred otherwise the extraction force can potentially crack the corner socket's solder joint.
  Bill

[Bill Shen]

I received a couple 64 meg SIMM 72, so I changed the CPLD equations to accommodate either 16 meg or 64 meg SIMM with a jumper change.  Picture below shows a CB030 with 64 meg SIMM at the back and a Quad serial card in the foreground.  The Quad serial card was originally designed for RC2014 bus, but because CB030's I/O expansion bus is very similar to RC2014 bus, Quad serial works with a few modification.  The OX16C954 chip can handle clock up to 60MHz, so the 24MHz 68030 clock is no problem.

I've successfully built 4 working rev0 CB030.  One board was shipped to Cecil B. since the design is named after him.

I'm ready to revise the design hopefully making it production ready.

[Bill Shen]

Took a break from MB020 and assembled the first rev1 of CB030.  The big change in rev1 is fixing the CF interface so it now can actually host a CF disk.  It works, but only with certain brand of CF disks.  680x0 seem to have more problems with CF disk interface.  I need to spend more time investigating.

The other improvement is hardware flow controls for the console interface.  68030 is fast enough so Kermit transfer does not require hardware flow controls at 38400, but when editing a large program with MicroEMACS the escape sequence of cursor keys can corrupt file without hardware flow controls. 

  Bill

[Bill Shen]

Built up 5 CB030 rev 1 and all 5 are operating consistently.  Improved the CF interface so more brands of CF disk will work, but still not all brands of disk.  Ironically the fastest CF disks work, but the slowest CISCO 64MB does not which is exactly opposite of most CF disk problems that I've encountered.  I may need to go to 4-layer PC board to solve the CF disk problems.

Made change to the way SIMM72 memory is interfacing so now it can handle 4/8/16/32/64/128 meg SIMM72 modules seamlessly, although for 8 and 32 meg memory, there are two blocks of non-contiguous memories that I still don't know how to fix automatically.  I'm relying on 68030's MMU to fix that.

Next big task is porting it to FreeBSD, but that's just brave talk, I have no idea how to do it.  So for the near term I'm pretty much done with CB030 development, I'll go ahead and ship out two boards to the people who've waited patiently for it.

  Bill

[ColleMalatra]

Hi Bill,
great project that I am following with a lot of interested. I am interested to buy a board (ideally with CPLD mounted on).
Emanuel 

[Bill Shen]

It has been a year since I last updated CB030 status.  A couple dozen CB030 rev1.1 are in the field, more if I counted the older version of CB030 and partially populated pc boards.  While I still have no clue on how to port FreeBSD, a version of Linux has been ported to CB030 by mikemac, https://www.retrobrewcomputers.org/doku.php?id=builderpages:mikemac:cb030

Because of higher part cost, assembled/tested CB030 is $75--more expensive than my normal "assembled/tested for $50" boards.  I do offer partially assembled kit (all SMT soldered and CPLD programmed) for $50, but if you are outside of USA, you may want to buy assembled board rather than kit because the heavier kit costs extra $10 shipping compare to lighter assembled board.  If you just want pc board plus SMT parts assembled and CPLD programmed, it is $20.  Shipping in USA is $6, International is $15.  I'm having problem shipping to Germany in the last 3 months.  Packages can take over 2 months to get there.
  Bill

[paul ruiz]

Hi Bill,

Interested in your CB030 for some retro-Unix stuff. I wondered what the status of the CF card is on the most recent revision. Is it the 8 bit interface, or is the 16 bit modification incorporated in the latest revision?

For some background, this is where I am coming from:

https://gitlab.com/pnru/cortex

https://gitlab.com/pnru/cortex/-/blob/master/doc/hacking.md

Paul

Op woensdag 17 maart 2021 om 15:39:05 UTC+1 schreef Bill Shen:

[Bill Shen]

Paul,
You've expressed interests in CB030, I replied to your an email, but it was unable to deliver.  I've sent you another email from a different email account.  I am not ignoring you, I'm just unable to connect with you.  Thanks,
 Bill

[Bill Shen]

I'm working on an "universal" VGA/keyboard board that will work with Z*80, 68K, and 6502.  This is based on the 40-pin RC2014-compatible VGARC which has a 4K dual port RAM with processor interface on one port and video controller on other port.  There are two challenges;
1.  Accommodate the addressing scheme of Z*80 16-bit I/O space to linear memory map of 68K and 6502
2.  Adopt RC2014 bus to RC6502 bus

I've had success modifying VGARC for CB030 that I want to describe in some details here.

VGARC is designed for Z80's 16-bit I/O space where most-significant byte of address is A0-A7 and least-significant byte of address is A8-A15.  Since VGARC has 4K dual port RAM, addresses A3-A0, A15-A8 are mapped to 4K dual port RAM.  For CB030, the addresses need to be A11-A0.  This can be done with jumpers that replace the connections to A15-A12 with A7-A4.  However, the resulting addresses are scrambled such that the most significant nibble is A3-A0, middle significant nibble is A7-A4, and least significant nibble is A11-A8.  This scrambled addresses can be straighten out by unscramble the address assignment of the 2nd port.  It is a brain twister but I was able to demonstrate that on a modified VGARC by cut/jumper the addresses and recompile CPLD with new address assignments.

CB030 has a 40-pin RC2014-like expansion slot.  It is not RC2014 compatible, but more like RC6502 bus.  The main difference is Z80's /RD is replaced with 68030's /DTACK0 and Z80's /WR is replaced with 68030's R/W.  Z80's /MREQ and /IORQ are mapped to 68030's I/O space at 0xFFFFD000-0xFFFFDFFF for /MREQ and 0xFFFFC000-0xFFFFCFFF for /IORQ.  The I/O device must provide data acknowledge when accessing 0xFFFFD000-0xFFFFDFFF, but no data acknowledge is needed for accessing 0xFFFFC000-0xFFFFCFFF.  So VGARC's PS2keyboard data and status are mapped to CB030 0xFFFFC0F4 and 0xFFFFC0F5, whereas VGARC's dual port RAM is mapped to CB030's 0xFFFFD000-0xFFFFDFFF.  More modifications to CPLD where existing /RD line is redefined to drive 68030's DTACK0 and RWB is inverted to drive dual port's /OE.

These are significant modifications but can be done with 5 jumpers and a different CPLD equation in production hardware.

Next post I'll show a CB030 driving the modified VGARC and the potential for a standalone 68030 computer.
  Bill

[Bill Shen]

Here is a picture showing modified VGARC plugged into CB030's expansion slot.  As mentioned in previous post, the address lines are scrambled from 68030 to VGARC's memory port, then the same de-scrambling is implemented in address lines of the VGA controller, so the display put out the standard banner correctly as if no scrambling has happened.  

The animated GIF shows VGARC can take input from PS2 keyboard.  Carriage return resulted in hardware scrolling of the screen.  After a few carriage returns, the demonstration software turned on 60Hz interrupt and update the big-font display every 100mS

This demo exercised all VGARC features on CB030.  It all seems to work well.  The next step is to build a standalone computer with VGA/PS2 interface and port it to CP/M68K.

  Bill