6502.org

Brad lose decimal, hex is most efficient! I realized this when modding Arlet's core for added instruxins. Learning hex is like learning how to ride a bike, you never forget once you learn it. Not looking down, just my .02$ Going back to lurking...

Yep, another +1 for hex. Hex maps to bits, and decimal doesn't. Octal maps to bits as well and was common back in the mini computer age. Fewer values to remember and thus faster to learn, but as octal maps to three and three bits it's less convenient for a lot of what we do. Works well for front panels though..

Indeed, but 1500 74HC254's and 187 multiplexers may be pushing it, even for this project!
I am at a standstill while I decide on the boot method now.

Looking at having logic stuff the 6502 memory from a 32k serial eeprom now.
Will only need maybe 2k of code to get a boot program running though.
The 6502 needs enough code to be able to initialize an SD card in Raw format.

I am also considering using modern parts for the external cartridge.
The cart. would use any available technology to stuff the SRAMs.
AVR with SDCard, ARM with config ROM, uC with serial PROM, etc
This would mean that as technology evolves, so could the cartridge.
This does not "really" violate my goals since the cart. is external, but it's not as cool.

Much to consider.
Too bad I have 20 dead ROMs!

Brad

Diode rom ??

http://hackaday.com/2013/10/18/making-a ... atrix-rom/


How short a boot loader can you write ??

The Elliot 803 managed it in 4 words!

http://www.billp.org/ccs/ElliottAlgol/i ... tions.html

Now that is cool indeed!
My 6502 will need enough code just to perform 2 tasks...

1) Get an SPI Flash initialized for read.
2) Fill it's own 64K program Memory from the Flash.

If I could get the code down to something like 64 bytes, I would actually consider Diode ROM, or just muxed Bytes.
That would certainly add some over-the-top real retro cool to this project.



This is one of those large decisions to be made... (A) Boot Logic on the board, or (B) Boot Logic on the External Cartridge.
Here are my thoughts so far on both, and how each one effects my original goals...


(A) Boot Logic on the board...
Obviously, this jives perfectly with my retro goals, as I only need common logic and ROM.
The easiest path would be a small 1K ROM mapped to Address Space.
The ROM would fill the 6502 with enough code to read the Cart. memory (probably SPI Flash).
From there the 6502 would fill all 4MB with Sound and Graphics data from the Cart. memory.
Another advantage to this system is that more then 4MB can be accessed.
The downside is that the Cart. memory has to be a certain type, like Flash only.
As memory technology changes (it always does), Vulcan Boot Logic goes obsolete.



(B) Boot Logic on the External Cartridge...
This is obviously the most flexible and obsolescence proof system possible.
Any conceivable type of storage can be used; flash, prom, uC, SSD, etc.
This will also be the fastest system, as the 6502 will only have a single 10ns 64K program memory.
Another plus is that others can create cartridges using technology they have available and know.
Another advantage... easy transfer from PC to Cartridge. An SD card is an obvious contender.
The one downside to this system is that modern components are required on the External Cartridge.
A simple AVR Tiny and a huge Flash could be used for instance, or something much more complex.
This doesn't really violate my rules as the Cartridge is external to the system.
The Cartridge can actually be yanked after bootup, so Vulcan would still be running off internal guidance.


Something is telling me that Option (B) is bar far the best choice, and perhaps my ROM failure is a sign.
I already have this system working, as this is how I booted the system during testing... AVR + SDCard.
Being able to cross develop easily on a PC and then use an SD card is certainly a bonus.
In 3-5 years when NOR and NAND flash is extinct (yes, it will happen), I won't need a redesign.


Hmmm... nothing like answering your own question by rambling on in a Forum! Option (B) it will be!
I shall bolt the 64K back onto the 6502, and run an external Cartridge Port again.

Development is back on track.
My next post will show the 6502 moving some Sprites around.

Cheers!
Radical Brad

You can make a very compact diode ROM by mounting the diodes vertically between two pieces of stripboard in 'cordwood' technique. If you run the copper strips at 90 degree angles, you have easy row and column access, and 100 bits per square inch. Just make sure you don't make any mistakes because they'll be almost impossible to fix.

If you go down to half the density, you could have two-pin sockets in adjacent perfboard holes, and plug diodes in vertically as needed. This does mean wiring up at least one direction - could perhaps use stripboard for the other, by tearing off alternate strips.

For historical context, I just read this about the 41-instruction bootstrap for EDSAC from 1949:

I am liking the Diode Matrix idea a lot!
Will have to see how minimal the code would be to read an SPI Flash memory once I get my hands on one.

Brad

How's a SPI flash going to be compatible with this rule

The cartridge is external to the unit.
Anything not part of the actual board is not counted (VGA Monitor, Speakers, Cartridge, etc).

Brad

I'm guessing a good chunk of the code in the diode matrix ROM will be devoted to initialization of the memory chip (before the real work of copying bytes begins). So, simpler initialization means a smaller diode ROM. Perhaps you'd like to consider this SPI EEPROM (datasheet attached) and see how its initialization compares with Flash. Speaking of ROM, don't forget that authentically retro TTL PROM's are still available (although no longer in production). For example a 16-pin DIP that contains 32 bytes. (74S188 and 82S23 are open-collector versions; 74S288 and 82S123 are tri-state output. Many other numbers are equivalent to these.) Access time is around 50 ns.

Diode matrix ROMs are cool, too, but will probably require wait states. If you're going that route anyway (wait states, I mean) then you can consider a matrix ROM storing multiple bits per element. IE: at each junction of the matrix, instead of having just a simple diode or no diode, have a single resistor or zener whose value conveys more than just a zero-one decision. Using four different values you get 2 bits per element. Using eight different values you get 3 bits per element, and so on. As the number of bits rises it rapidly becomes more challenging to build a reliable circuit. Even so, if you were crazy enough to build a large ROM this way then 3 or more bits per element might be justified. But IMO for a small ROM there's no sense going beyond 2. I admit it's pretty whimsical. But I have some notes on how it could be not-too-inefficiently done...

It's best if you know how many bytes will be required first. That'l affect you decision re ROM type.

cheers,
Jeff

I assume this is because you have the diode to provide a '1', but need a pull-down resistor to provide the '0' (or the other way around), and the resistor adds an RC delay. You should be able to speed it up by adding a low impedance n-type MOSFET parallel to each resistor, and turning that on during idle phase of the clock to precharge all the outputs to '0'.

I was also thinking that you could attach a SPI memory chip to the VGA output of a PC, and program it by displaying an image.

That's a great idea!

Jeff's idea could be extended to use an 8-bit flash, or half-flash, A/D converter which has no setup requirement and can be read like a memory location. Very simple. For vintage's sake, I think the ADC0820 has been out for three decades, and it'll do something like three-quarters of a million conversions per second this way. The small integral nonlinearity (INL) error (like all converters have) and the resistor tolerance and the resistor inventory you'll need to buy may pretty much rule out getting 8 bits per resistor, but four is well within reach. Modern carbon-film resistors marked for a tolerance of 5% are usually within 1%, and you could use a logarithmic scale anyway to ensure dependability. If you don't want to use the A/D converter (like because you want to be even more self-sufficient), you could make a 4-bit flash converter yourself with four common quad op amps.