BDD asked the question about 22V10 logic utilization with 32 bytes of ROM code. I've given an answer, but the question has lingered and ... festered

By changing the data pins assignment, I can squeeze more and more bytes of ROM code. So do I have enough ROM to bit-bang receive? Another word, can I get rid of the serial device and replace it with a software bit-bang serial port? Can I build a 6502 computer with just 6502, RAM and 22V10?

Memory map:
ROM: $F800-$FFFF
Software Serial: $F000-$F7FF
RAM: $0-$EFFF

Here is a bit-bang receive program in 22V10 ROM that gets 254 bytes of binary data from serial port and saves to addresses $2-$FF then jumps to $2 to execute. The serial data bit comes in on data [7].


It is 49 bytes and it fits!

I'm going to build a barebone 6502 computer and call it Muntz65 as a tribute to "Madman" Muntz, patron saint of every hardware engineer's boss.
Bill

Interesting....

My current project is somewhat minimal too, but does feature a ROM (also a GAL) and it bit-bangs serial too...

Curious about your clock and baud rates - I have a 2mhz CPU and at 9600 baud the loop delay (same idea as yours loop on a register) is about 36... I have experimented to find out how much leeway I have and reckon I have scope to go much higher - 57600 if I wanted to...

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Nice! You should be able to ROL SerData and then ROR A, and get rid of SerVal. Then I would consider using PHA to load the program into the stack instead of to page zero which should save some more bytes - no need to count bytes in X or save/restore it, you can TSX and then BNE to loop until the stack is full. The stop bit delay seems to only apply for the last byte received, and so it could move into the loaded code instead.

However I've wondered in the past whether the best route here is to minimise complexity rather than size. e.g. unrolling a loop 8 times, where the loop is aligned to a power of two, should have no cost in PLD complexity. In some cases that may be quite a powerful thing to take advantage of.

Edit: something like this:

So long as the NOPs pad to a power of two you can repeat that eight times for free, subject to available address space.

Interesting point!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I've realized and fixed the stop bit delay and saved 2 bytes in the process. There are definitely room for smaller code, but I was interested in how big the ROM can be and still fit in 22V10. The power-of-2 is an interesting idea worth exploration; it is like data compression--how to arrange data to get best compression. As much as I've maligned WinCUPL, it does have a neat "don't care" feature in the truth table statement that can reduce the complexity of sum-of-products.

To answer Gordon's question, CPU clock is 7.37MHz and serial baud is 115200. Since it has no ROM, the clock can be crank up much higher; I'm thinking of 30MHz or so. An I2C adjustable clock can be quite useful to tweak the bitbang sampling to middle of the serial bit transitions.

Z80 has better code density, so ROM code for Muntz80 should be easier.
Bill

This is Muntz65 prototype built on a CRC65 proto board. It is pretty simple, mostly I just wired in signals to 22V10. I modified the ROM bootstrap so it will load/run 256 bytes of program from $300-$3FF. The ROM bootstrap program size is now 42 bytes. Attached are schematic, ROM bootstrap listing, and 22V10 design file.

It is ready to go, I'm settling down for a debugging session
Bill

Edit (12/6/23) It is working. I updated the 22V10 design file and serial ROM file.

It is working.

The bootstrap in 22V10 can load a 256-byte Intel Hex loader which, in turn, load Muntz65 monitor which is a simple monitor with 4 functions, set memory, display memory, load hex file, and go. The CPU clock is 7.37MHz and serial baud is 115200. It will run with 14.7MHz CPU with serial baud at 230400, but it will not run 29.5MHz. I'll try 25.175MHz.
Bill

That's great! Bitbang serial is tricky with variable clock rates. I've made one where I can specify the clock speed using jumpers on a VIA port, so that I can change the speed easily without updating the code - but I don't think you have a VIA in this system.

By the way, you can write Data.oe = ... rather than having separate lines for each pin.

Thanks for the tip on treating D[7..0] as a bus. WinCUPL has nice bus construct for groups of signals. Being new to WinCUPL, I'm a little afraid of using it. However, the compile does generate a .sim file with all the bus signals break out, so I can look at .sim in case I'm unsure.

I've tweaked the 22V10 and software to run Muntz65 at 25MHz with serial baud of 115200. The problem before was not 6502, RAM, nor 22V10 but the way serial receive is sampled by data bit 7. The sampling is done with a 4.7K resistor from serial receive to data bit 7, which is too weak to drive the combined capacitance on data bit 7 due to RAM, 6502, 22V10 loadings; the combined capacitances + stray pcb capacitance is maybe 25pF, so the RC time constance is about 120nS. At 25MHz, the instruction "BIT SerData" has slightly lesser than a clock (40nS) period to sample the data bit 7 which is just too short. I did two things to speed it up,
1. reduced the resistor to 2.4K thus cutting RC time constant to 60nS, but with increased loading to RAM/6502/22V10,
2. replaced the "BIT SerData" instruction with "ROL SerData" which has a dummy cycle accessing SerData prior to actual sampling SerData; this gives two clock periods for the RC network to settle to final value.

So it works at 25MHz, but the sampling resistor between serial receive and data bit 7 remained a weakness of the design; it is susceptible to loading on data bus.

All in all, I'm pleased with this simple design. It based on readily available components and 22V10 can be programmed with TL866II-Plus; all components are DIP so can be prototyped on one strip of solderless breadboard; and 25MHz 6502 is no slouch. The same design approach can be ported to Z80 and other retros.

One drawback is the fact software needs to be reloaded every reset. TeraTerm script eases the drawback somewhat, but a battery, couple Schotkky diodes to RAM plus modifications to bootstrap code to jump to RAM if no serial input detected may solve most of the reloading problem.

I've created a homepage for Muntz65.
Bill

That's very impressive as usual! What specific 22V10 are you using, what is its rated speed?

I guess you could sacrifice one of the high address lines to feed RX in, and modify the equations for D7 to accommodate it if possible. Aside from needing more product terms, you'd lose some of the address space from RAM.

Another option may be to multiplex TX and RX with resistors instead, as presumably your bitbanging doesn't support full duplex anyway?

The bus syntax also works for pin assignments - you can assign multiple pins in one line, and use ranges e.g. Pin [14..21] = [ D0, D6, D2, ... ]

I'd like to build one of these when I have the time, thanks for sharing the design.

Nice!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I figure you would like dummy cycle being used in a positive way.

I wasn’t sure about the dummy cycle addressed to SerData, but confirmed it with scope measurements. It was nice to see the RC decaying over two clock periods.
Bill

I don't know for sure what is speed rating of my 22V10. It is used part I purchased from random eBay seller, it is supposed to be -15 part.


It is definitely simplex serial. I have to modify the file download routine to not respond with '.' for every packet received otherwise I'll lost every other packet.
Bill

Now you've gotten *me* wondering. Although I lauded the RMW idea, I now suspect I was too hasty, and in fact it has no advantage.

The Read-Modify-Write consists of two reads then a write... and, as you say, the RC now has two clock periods (the two reads) during which to decay, so the RC curve gets drawn out longer on the scope.

But the CPU ignores the data that's returned on the second read. That's when it's internally doing the "modify". The outcome depends on the data that's returned on the first read.

So, at the moment I'm thinking the RMW "improvement" is actually no better than the BIT you were using in the first place. Or am I still confused??

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

What you said makes perfect sense, unless there is something special about rolling D7 into carry flag—condition code tends to be the long pole in execution path.

It is easy enough for me to restore the BIT SerData instruction and see if the program still works at 25Mhz. Perhaps I should’ve used LDA SerData,X instruction?

I’ll try that first thing tomorrow morning.
Bill