Boot Loader / ROM Emulator (64K Ram)

[Mike-K8LH]

I'd like to add 'boot loader' & 'ROM emulator' features to the Crab Apple by modifying the hardware and PIC firmware a bit and using a 'blind interface' technique (from Nicholas FitzRoy-Dale). The technique allows the PIC to 'push' and 'pull' instructions and data to and from the 6502 over the data bus for the purpose of loading RAM from one or more pseudo ROM images in PIC flash memory. The technique works for both WDC and non-WDC CPUs but requires the ability to turn memory on and off and so I was thinking about using the push button I/O pin as both an input and an output to control memory. I was wondering how this technique/method might compare to what you're working on for a 'boot loader'?

Cheerful reqards, Mike - K8LH

[gcswales]

Hi, I think I already use that technique but didn't know it was called 'blind interface' I refer to it as 'bus injection'. You take total control of the 6502 (via the reset & clock) and 'inject' onto the data bus a series of LDA & STA pairs, getting the 6502 to 'load' in your data byte then 'store' it at a specified location. As you noted; you need to disable the on-board memory for part of this or you will get a conflict on the bus.
It only takes a few ms for the PIC to hand over an 8k image at boot-up then the PIC resets the 6502 and it starts executing the image.
On my setup the PIC runs XMODEM for 2 seconds at boot-up which makes it very simple to upload a new image to the PIC (2-3 seconds). The PIC stores the image in flash, so the system can be stand-alone.
The second schematic on your post is interesting, however there are some changes I would make (just my opinion).
64k chips are very rare (expensive) where as 32k and 128k are common and cost (almost) the same so I'd use a 128k chip and learn to live with only using half of it. I'd take the /CS1 line to the PIC for disabling the memory. I'd pull CS2 to +5v via a resistor and then use the CS2 as a 'memory inhibit', active low. Then connect this line (via diodes) to any /IO_EN lines. This way the memory is always enables unless an IO device is enabled so (with jumpers) we could disable an IO device and the gap would be filled with RAM.
I would 'slacken' the address decoding; get rid of the 74hc151. Use a pull-up resistor on pin 1 (/E) of the 74hc139 and a transistor to pull pin 1 to ground. The transistor can be driven by A15 of the 6502. Pins 2 & 3 of the 74hc139 would be driven by A13 & A14. This way the IO decoding is only active for the upper 32k and each IO device gets an 8k address space; $Fxxx, $Exxx, $Dxxx, and $Cxxx.
Yes it's a waste but it's minimal.
So we have 4 /IO_EN lines but we're only using 2 (pin5 to the PIC and pin 7 is not connected to anything so our RAM will fill the gap and act as ROM).
By just adding an LED, resistor and 40-way IDC connector you can have Compact Flash storage, which is very simple to use; see my other github repo.
You could also add some GPIO by re-wiring the lower half of the 74hc139 chip:-
pin 13 - /IOCS (from spare IOCS line on upper half of 74hc139)
pin 14 - R/W
pin 15 - PH1 (active low clock)
pin 9 - /RD
pin 10 - /WR
pin 11 - /IN
pin 12 - /OUT
The line /IN could then be connected to the /OE of a 74hc573 and provide 8 inputs.
The line /OUT could be connected to /E on a 74hc259 and provide 8 addressable outputs.

Now every one of the above changes takes us further away from Apple 1 hardware compatibility but is that an issue. In my (humble) opinion; so long as you have the console compatibility then the majority of software written for the Apple 1 will work.
The 'ROMLESS' solution is great for development as it speeds up the whole 'code-compile-test' cycle, which is done a lot more when coding in assembly.
The mass-storage adds a whole new level of use to the system making it stand-alone and flexible.
Finally the 16 lines of GPIO are great for users wanting to experiment with low-cost SPI and I2C hardware.
You could even hook up one of the output lines to a speaker (via a transistor) and BOOM! A sound card to rival and IBM PC.
Hope I haven't over-loaded you with crap. I'd be interested to hear your thoughts.
Finally; I am working on an OS for minimal 6502 systems (like the Apple 1) and will be posting progress on my github.
Best regards,
Geoffrey.

[Mike-K8LH]

Some great suggestions and insights. Thank you, Geoffrey.

Concerning 64K RAM chip prices... I've purchased skinny 15-nanosecond 64K and 128K SRAM chips, average price around 67¢ each, including shipping, in quantities of 5 or 10 from vendors on AliExpress over the last several years. Prices are a bit higher now. Search for any of the following devices;

• IS61C512-15N (64K)
• IS61C1024-15N (128K)
• W24512AK-15 (64K)
• W241024AK-15 (128K)
• UM61512AK-15 (64K)

Here's an example listing (shipping is $1.99);

Cheerful regards.

[Mike-K8LH]

Hi Geoffrey. Just wanted to mention I designed a 'development' system similar to what you describe but I'm using the uC as a full-blown ROM Emulator of sorts. That is, the system has 64K RAM but I've kept the ROM as an "image store" and to provide the user with a free programmer for 28C256 EEPROM's or 39SF010A Flash ROM's. The ROM Emulator allows you to switch between "run" and "emulator" mode where you can load one or more HEX files into 64K RAM. You can also program the 64K RAM image into the 64K 'A' or 'B' portion of the Flash ROM to save your work or to create the 64K image that's automatically loaded into RAM at power-up. I just started building my latest prototype PCB (below). I'd love to add this capability to the Crab Apple PIC UART but I need a few more pins (upgrade to a 28-pin 18F27Q43, perhaps?).

[gcswales]

So I've finished (I think) R2 of the Crab Apple.
I'm calling it Crab Apple Plus.
It's exactly the same size as a credit card, but not tested.
Here are the highlights:-

• Console is mapped to 0xD000 - 0xD7FF
• OUT and IN strobe mapped to 0xD800 - 0xDFFF so you can hook up some TTL latches for additional IO
• IDE Port mapped to 0xC800 - 0xCFFF
• Spare CS on expansion port mapped to 0xC000 - 0xC7FF for experimenting.
• /RE and /WE on expansion port.
• PIC will handle ROM bootloading into RAM.
• PIC handles UART
  Here is the schematic and pcb layout:-
  CRAB_APPLE_PLUS_SCHEMATIC.pdf
  

[Mike-K8LH]

Hi Geoffrey. I've been studying this since you posted it a couple weeks ago. This is a really neat design. A couple brief comments, if I may...

Moving the reset switch and retaining the MCLR function is nice because now someone could use an inexpensive ~$2 Nano clone to program the PIC if he/she doesn't have a PICKIT or similar programmer. I wrote an Arduino 'sketch' a couple years ago that programmed a PIC with firmware contained in an array and it worked quite well.

The diode/transistor address decoder is brilliant. It's tempting to try this in my design but I don't have a scope or anything that might be used to characterize the propagation delay.

Take care. Have fun. Happy Holidays.

[gcswales]

Hi Mike!
Yes, I moved the reset to free up the MCLR line so people can use the new Microchip SNAP programmer that only uses low-voltage programming. I can't believe the PicKit4 is £100+, when did that happen?!?
Does your Arduino programmer work with the new PIC18FxxQ range? I think you should resurrect your programmer. I think it could become very popular for hobbyists. Have you thought about putting XMODEM in it to upload the HEX image? You could program the code as you upload each package.
The diode/transistor thing is a bit of a dirty hack and may be way too slow, but I thought I would give it a go. I'll let you know how I get on.

[Mike-K8LH]

The Nano sketch can program Q40, Q41, Q43, Q83, and Q84 devices so far, however, the PIC firmware is installed in the sketch as an array. The idea was to provide a user with a ready made sketch to initially program a PIC for some dedicated project.

[Mike-K8LH]

Also wanted to ask if you might consider porting the Crab Apple UART to a 28-pin device like the 18F27Q43? It has eight (8) CLC blocks and double the flash memory. I wouldn't mind using the extra pins and CLC's for address decoding or other ROM Emulator type functions.

Cheers. Happy Holidays, Mike

[gcswales]

Hi Mike, I already have something similar running on a 28-pin PIC18F27Q43. It's an interesting board I'm using to develop my OS on; the 'Blind Loading' make development much faster than pulling out an EPROM. At present I have the UART and blind-loader working. I have had the VGA and PS/2 keyboard working, but not all together. The serial RX is handled by the DMA but I also need to get the DMA handling the parallel port, then it would free up the code to handle the VGA. The code is written in PIC Assembly which makes firmware development very slow but does give me VERY accurate timing.

[Mike-K8LH]

Sounds fascinating, Geoffrey. Serial via a DMA channel? VGA output? PS/2 keyboard input? You're a wizard.

I used to do everything in PIC assembly but being forced to run and update MPLABX to use the newer devices has left me a bit behind on the new assembler. Also, my tired old laptop hangs up on the more recent MPLABX versions so I just bought a new PC and I'm in the process of installing apps' and moving data, etc. I've got MPLABX v6.20 installed and it seems to be working well.

I was going to try to port the majority of your Crab Apple 1 code to a 27Q43 but I wasn't quite sure how to setup the CLC's and Data Modulator. I just need to find time to study your code and the datasheets some more.

Can't wait to see what you come up with. Take care. Have fun.