Neolithic Romless

[barnacle]

Inclined to agree about the pull up. It'll still need something to block the 5813 from writing though.

Neil

[barnacle]

I have a soic hc32 dead-bugged on top of the 5813

Neil

[Ken KD5ZXG]

SN74LVC1G17 Schmitt buffer in par w resistor for self-latch.
Not at the floating open output, but at the confused input.
Hold last strongly established state with weak bleed-back.
Never tried, could be talking nonsense...

[barnacle]

Not sure that helps; the SOUT output from the 5813 has to be actively held high when the output pins are disabled (i.e. ~RESET and BE are high). As that signal already exists, it's simple just to OR SOUT and ~ENABLE. Then AND the output of that and the 65C02 RnW to give a write to the rams which is always valid, and never comes from the 5813 once it's reached the end of the load and turned off.

Neil

[barnacle]

I've found a tool which allows me to compare hex files on Linux: meld. Which looks rather nice.

Comparing the two (my build using AS65, and my modified version of Grant's binary) it looks like there are only a half dozen changes in the body of the code. There shouldn't be any, of course, so now the task is to find out which and why - which just got two or three orders of magnitude easier. There are more differences at the top, where the input and output code lives, but I know there's different code in there.

TBC...

Neil

[GARTHWILSON]

barnacle wrote:

I've found a tool which allows me to compare hex files on Linux: meld. Which looks rather nice.

Using Linux, I've used SRecord 1.65 at https://srecord.sourceforge.net/ which has lots of file conversions and utilities.

[BigEd]

(I thought I'd heard of meld... searched my emails, and it turns out it was back in 2012. Oh, how time passes.)

I'm rather liking this project, BTW, although I can't say I've quite got a mental picture of the data flow. I'm thinking of it as a ROMless SBC which runs a hard-coded pre-boot protocol allowing pokes from the serial port.

[Chromatix]

I think it's actually set up so that the "magic serial widgets" (the 5813s) provide both the data and the address for the 6502 bus, and execute a write cycle to RAM every time the data register is loaded. The fourth widget just allows the system to be switched out of "bootstrap" mode and bring the 6502 out of reset. So it's basically using a bus pirate instead of a ROM.

I mentioned earlier in the thread that I had an alternative idea along these lines. Using only two 5813 devices, I would use the 6502 itself (executing NOPs) as the address generator. One 5813 would provide data, and some glue logic would alternate between presenting that data on the bus along with a write-enable to the RAM, and presenting a suitable NOP opcode to the 6502 with a clock or RDY pulse. The second 5813 would allow both selecting this mode of operation, and manipulating the 6502's /RST line (or maybe /NMI). Data can then be loaded to arbitrary addresses by presenting that address as the reset vector, so that the 6502 begins executing the NOPs there.

[barnacle]

Yes, it's effectively a bus pirate. Remember this was a proof of concept... Three of the magic serial widgets (I like that!) are loaded with the address high, address low, and data; the write to the data widget automatically writes to ram on completion. I think that this implementation is conceptually simpler that Chromatix' idea, and possibly faster: my file converter (which handles hex files one line at a time) only includes a write to the address high widget at the start of each line, and if the page changes during a line (I've never seen that but it's theoretically possible) so for the majority of data it's sending only four packets per byte instead of six - saving a lot of time in the load.

The last widget is somewhat wasteful but provides a solid 'done now, go away and never darken my doors again' reset, permanently isolating the serial decode and starting the processor at the just-sent reset vector.

Incidentally, using meld I found the error at the third difference (the others were just changed pointers to the I/O routines): I had mistakenly replaced

Code: Select all

    jcc xxxx

with

Code: Select all

    bcc $+3
    jmp xxx

Oops.

Anyway, the work flow is exactly as I desired; in the same way that one might use an Arduino or Nucleo, it's straight forward:

• Edit code on the host machine (assembly, C, whatever)
• Assemble/Compile code to a hex file
• Convert hex file to a binary stream file
• Set the serial port to 19k2 baud
• Send the binary file (an 8kB file takes around 18 seconds)
• Wake up the terminal (minicom in my case)
• Rinse and repeat

The last three steps use individual commands at present but might conveniently be included into a single shell/batch file (actually, that might include the conversion step, too).

This build is effectively Grant's minimal build: Ram for the bottom half, a minimally decoded ACIA at 0xa000-0xbfff, and then ram for the top quarter. So while what I'm doing at the moment is writing basic into 0xc000 for eight k, it's equally simple to drop an image into the bottom half, anywhere there's ram. The only critical thing is to remember that you have to write the reset and (if used) interrupt vectors. It uses two (well, one and a half) 32k rams simply because I had them in the bits box, and it runs at 1.8MHz because it uses that as the serial clock.

I probably won't build another hardware version, but if I did it would include:

• The OR gate that isolates random writes
• A separate reset for the processor so that it can be reset without reloading the data (a full 64k upload would be over two minutes)
• The two spare inverters used to drive LEDs: one lit when the data is loading and one lit when serial data is incoming. Just for pretty...

The basic technique should of course be adaptable to any 65C02 design - it would require extra buffers for an NMOS processor which lacks BE, of course - and similarly to any other processor.

I'm really rather pleased with it.

Neil

[BigEd]

(I might be confused: are these mentions of 5813 intended to be 8153? That is, the SN74LV8153 Shift register from Texas Instruments)

[barnacle]

SN74LV8153 throughout from me, except where I spelt it incorrectly as 8152 on the front silks...

Neil

[barnacle]

OK, here's rev B - probably final, and just incorporating minor bugfixes and blinkenlights. I probably won't build this one.

6502_lv8153.pdf

(786.84 KiB) Downloaded 136 times

Kicad files and gerbers for this version available if anyone wants to play.

Neil