Zero glue logic 6502 SBC?

[plasmo]

I have a simple 4-function (load/display/modify/go) monitor working on ZeroGlue6502 (ZG6502), so I sent out the design to JLCPCB. The prototype ZG6502 is documented here.
Bill

[barrym95838]

From ZG65Mon.lst:

Code: Select all

00F004  1               ;load 4K of data from EPROM to RAM
00F004  1               loop0:
00F004  1  BD 00 F0     	LDA $f000,x
00F007  1  9D 00 70     	STA $7000,x
00F00A  1  E8           	INX
00F00B  1  D0 F7        	BNE loop0
00F00D  1               loop1:
00F00D  1  BD 00 F1     	LDA $f100,x
00F010  1  9D 00 71     	STA $7100,x
00F013  1  E8           	INX
00F014  1  D0 F7        	BNE loop1
00F016  1               loop2:
00F016  1  BD 00 F2     	LDA $f200,x
00F019  1  9D 00 72     	STA $7200,x
00F01C  1  E8           	INX
00F01D  1  D0 F7        	BNE loop2
00F01F  1               loop3:
00F01F  1  BD 00 F3     	LDA $f300,x
00F022  1  9D 00 73     	STA $7300,x
00F025  1  E8           	INX
00F026  1  D0 F7        	BNE loop3
00F028  1               loop4:
00F028  1  BD 00 F4     	LDA $f400,x
00F02B  1  9D 00 74     	STA $7400,x
00F02E  1  E8           	INX
00F02F  1  D0 F7        	BNE loop4
00F031  1               loop5:
00F031  1  BD 00 F5     	LDA $f500,x
00F034  1  9D 00 75     	STA $7500,x
00F037  1  E8           	INX
00F038  1  D0 F7        	BNE loop5
00F03A  1               loop6:
00F03A  1  BD 00 F6     	LDA $f600,x
00F03D  1  9D 00 76     	STA $7600,x
00F040  1  E8           	INX
00F041  1  D0 F7        	BNE loop6
00F043  1               loop7:
00F043  1  BD 00 F7     	LDA $f700,x
00F046  1  9D 00 77     	STA $7700,x
00F049  1  E8           	INX
00F04A  1  D0 F7        	BNE loop7
00F04C  1               loop8:
00F04C  1  BD 00 F8     	LDA $f800,x
00F04F  1  9D 00 78     	STA $7800,x
00F052  1  E8           	INX
00F053  1  D0 F7        	BNE loop8
00F055  1               loop9:
00F055  1  BD 00 F9     	LDA $f900,x
00F058  1  9D 00 79     	STA $7900,x
00F05B  1  E8           	INX
00F05C  1  D0 F7        	BNE loop9
00F05E  1               loopa:
00F05E  1  BD 00 FA     	LDA $fa00,x
00F061  1  9D 00 7A     	STA $7a00,x
00F064  1  E8           	INX
00F065  1  D0 F7        	BNE loopa
00F067  1               loopb:
00F067  1  BD 00 FB     	LDA $fb00,x
00F06A  1  9D 00 7B     	STA $7b00,x
00F06D  1  E8           	INX
00F06E  1  D0 F7        	BNE loopb
00F070  1               loopc:
00F070  1  BD 00 FC     	LDA $fc00,x
00F073  1  9D 00 7C     	STA $7c00,x
00F076  1  E8           	INX
00F077  1  D0 F7        	BNE loopc
00F079  1               loopd:
00F079  1  BD 00 FD     	LDA $fd00,x
00F07C  1  9D 00 7D     	STA $7d00,x
00F07F  1  E8           	INX
00F080  1  D0 F7        	BNE loopd
00F082  1               loope:
00F082  1  BD 00 FE     	LDA $fe00,x
00F085  1  9D 00 7E     	STA $7e00,x
00F088  1  E8           	INX
00F089  1  D0 F7        	BNE loope
00F08B  1               loopf:
00F08B  1  BD 00 FF     	LDA $ff00,x
00F08E  1  9D 00 7F     	STA $7f00,x
00F091  1  E8           	INX
00F092  1  D0 F7        	BNE loopf
00F094  1               
00F094  1  4C 97 70     	JMP *+3-$8000		;continue execute this program in RAM

Is there any reason for not stuffing it all into one big loop, saving 45 bytes?

Code: Select all

00F004  1               ;load 4K of data from EPROM to RAM
00F004  1               loop0:
00F004  1  BD 00 F0     	LDA $f000,x
00F007  1  9D 00 70     	STA $7000,x
00F00A  1  BD 00 F1     	LDA $f100,x
00F00D  1  9D 00 71     	STA $7100,x
00F010  1  BD 00 F2     	LDA $f200,x
00F013  1  9D 00 72     	STA $7200,x
00F016  1  BD 00 F3     	LDA $f300,x
00F019  1  9D 00 73     	STA $7300,x
00F01C  1  BD 00 F4     	LDA $f400,x
00F01F  1  9D 00 74     	STA $7400,x
00F022  1  BD 00 F5     	LDA $f500,x
00F025  1  9D 00 75     	STA $7500,x
00F028  1  BD 00 F6     	LDA $f600,x
00F02B  1  9D 00 76     	STA $7600,x
00F02E  1  BD 00 F7     	LDA $f700,x
00F031  1  9D 00 77     	STA $7700,x
00F034  1  BD 00 F8     	LDA $f800,x
00F037  1  9D 00 78     	STA $7800,x
00F03A  1  BD 00 F9     	LDA $f900,x
00F03D  1  9D 00 79     	STA $7900,x
00F040  1  BD 00 FA     	LDA $fa00,x
00F043  1  9D 00 7A     	STA $7a00,x
00F046  1  BD 00 FB     	LDA $fb00,x
00F049  1  9D 00 7B     	STA $7b00,x
00F04C  1  BD 00 FC     	LDA $fc00,x
00F04F  1  9D 00 7C     	STA $7c00,x
00F052  1  BD 00 FD     	LDA $fd00,x
00F055  1  9D 00 7D     	STA $7d00,x
00F058  1  BD 00 FE     	LDA $fe00,x
00F05B  1  9D 00 7E     	STA $7e00,x
00F05E  1  BD 00 FF     	LDA $ff00,x
00F061  1  9D 00 7F     	STA $7f00,x
00F064  1  E8           	INX
00F065  1  D0 9D        	BNE loop0
00F067  1               
00F067  1  4C 6A 70     	JMP *+3-$8000		;continue execute this program in RAM

??? If ZP is available right away, you can save 72 additional bytes with (ZP),Y:

Code: Select all

    txa
    sta $80
    sta $82
    tay
    lda #$70
    sta $83
    lda #$f0
    sta $81
loop0:
    lda ($80),y
    sta ($82),y
    iny
    bne loop0
    inc $83
    inc $81
    bne loop0
    jmp *+3-$8000

[plasmo]

Cool! thank you, that's much better code!
ZP is not available immediately after power up; the entire memory space is EPROM for read operations for about 350mS.
Bill
Edit: Mike, This is what the board looks like. Would you like me to mail you a blank board? PM me with your address if you like one.

[barrym95838]

Ah, got it. But then is it okay to jmp *+3-$8000 so soon?

[barrym95838]

plasmo wrote:

Edit: Mike, This is what the board looks like. Would you like me to mail you a blank board? PM me with your address if you like one.

Oh, thank you for the kind offer, but please find someone else more likely to make proper use of it ... I'm firmly in software mode for the foreseeable future, and the best use I would have for it now is as a book marker, which is not a polite use of resources.

[plasmo]

barrym95838 wrote:

Ah, got it. But then is it okay to jmp *+3-$8000 so soon?

When program is running below $8000, it is reading data from both RAM and EPROM, but because RAM's content is same as EPROM, there are no contention. EPROM's address15 is tied to +5V or ground, so EPROM contents from $8000-$FFFF are duplicated at $0-$7FFF.
Bill

[Sheep64]

Collectively, I think that you've solved it. Furthermore, the memory map is quite nice:-

• $0000-$7FFF: Use one RAM chip with active high and active low chip select. Connect A15 to the active low chip select and PHI0 to the active high chip select. This correctly handles spurious writes.
• $8000-$BFFF: Use one 6522 or similar 65xx peripheral. Connect A15 to active high chip select. Connect A14 to active low chip select. 65xx peripherals provide their own internal read/write qualification.
• $C000-$FFFF: Tie one ROM's active low output enable to ground and use eight separate resistors to resolve contention on the data bus. Conceptually, the ROM is at the far end of the data bus. Each resistor should separate one data pin of the ROM from the data pins of the processor, RAM and I/O.

Writes to $C000-$FFFF may also be used for sound and video output.

This has been a very educational exercise and it has certainly honed by ability. Like many others, I wasn't optimistic about the outcome. I wrongly assumed that it wasn't possible, that the vectors would be conflated or that the memory map would be horrendous with, for example, 32 bytes of ROM on every page. Even if the exercise itself were impractical, it spurred me to consider more practical yet fast implementations. Most significantly, compare suggestion to place ROM and I/O on every 256 byte page and suggestion to place ROM and I/O on every 65816 64KB bank.

I planned to write an article which describes use of one half of a 74x139 dual 2-to-4 demultiplexer to replace the two NAND gates typically used to provide 32KB RAM, 16KB I/O, 16KB ROM addressing while the other half of the 74x139 replaces the three NAND gates typically used to provide read/write qualification. Unfortunately, five NAND gate decode schemes occur as frequently as five wheel vehicles. I hoped to make the 32KB/16KB/16KB scheme more popular by reminding people that it can be reduced to one integrated circuit.

However, with suitable RAM, it appears that even the 74x139 is redundant. I may write this article anyhow because there are further useful cases involving one or more 74x138 mono 3-to-8 demultiplexers. Specifically, it permits 48KB/8KB/8KB decode or 56KB/4KB/4KB decode across multiple banks. Variants are sufficient to implement virtualization of Commodore, Apple or Acorn binaries. Also, I found that a spare half 74HC139 can be used with a 64MHz crystal. This has obvious application for anyone wishing to exceed 30MHz.

[plasmo]

This is pc board version of the ZG6502. It is designed for PacTec's CM5-125 enclosure as shown in the picture.

I have created a ZG6502 homepage (currently under construction) and will put all design information there. The memory locations $C000-$FFFF are suitable for other I/O boards 350mS after reset. This is why I have 3 RC6502 expansion slots and added a "inhibit" signal to disable the I/O in locations $C000-$FFFF during the 350mS bootstrap.

Because of the simplicity, I think this board can potentially run up to 20+MHz with appropriately fast RAM and EPROM.

WDC's 65C02 and 65C51 are expensive, but if built with used 6502 and 6551, this can be an inexpensive (<$20) way of getting into world of 6502.
Bill

[Sheep64]

plasmo on Mon 10 Jan 2022 wrote:

inexpensive (<$20) way of getting into world of 6502.

I hadn't considered cost as the top priority. I was aiming for speed without compromise and then a version which is less than USD50. However, a streamlined design is already less than USD50.

[tokafondo]

I've thinking also about a ZGL 6502 system. The idea is to have the CPU share the RAM with the rest of the chips, in a way that it reads or writed every half clock and the rest of the chips access the RAM in turns in the other half. A sort of what happens in the Commodore 64 (and other systems, sure) with the CPU and the VIC-II.

And for the bootloader, what about the idea of having a counter read every address in a ROM, and somehow write every data read in the RAM, and then have the 6502 read the boot vectors once done?

Still very early concepts with no development at all by myself, just to contribute to the thread.

[GARTHWILSON]

tokafondo wrote:

And for the bootloader, what about the idea of having a counter read every address in a ROM, and somehow write every data read in the RAM, and then have the 6502 read the boot vectors once done?

Still very early concepts with no development at all by myself, just to contribute to the thread.

I just tentatively finished a project that does a similar thing for a ROMless '816 system.  It hijacks the motherboard's Φ2 source (also disabling RAM's output), and its reset, then as it lets the processor out of reset the first time, it watches the VP\ output and feeds the data lines an artificial reset vector, then watches the VDA and VPA lines for the first instruction fetch, and then starts feeding LDA#...STA instructions to put the bootloader code into RAM.  You can have multiple stretches of RAM, held as separate records in the I2C-6 EEPROM module plugged into the bootloader board.  [Edit, 7/28/22:  The I2C-6 EEPROM module is on the front page of my site now, and there's a link to the data sheet there.]  Each record has a record type field, a starting address, a number of bytes in the payload, a link to the next record, and the program or data itself to load into RAM.  When it has finished the last record, it puts the '816 back in reset, releases the clock source it had hijacked, puts its own data lines in hi-Z, and releases the RST\ line so the '816 can now boot up with the vectors and bootloader you just put in RAM.  It uses a PIC16 microcontroller.  I plan to make it available to others.  I just have to figure out some details of how to do that; for example, many users won't initially have any way to put the data in the serial EEPROM.

[Michael]

GARTHWILSON wrote:

It uses a PIC16 microcontroller. I plan to make it available to others. I just have to figure out some details of how to do that; for example, many users won't initially have any way to put the data in the serial EEPROM.

Which PIC are you using? How much EEPROM/Flash storage do you need? If it's a relatively modest amount, you might consider using a 20-pin 18F16Q40 (64K Flash) or a 28-pin 18F27Q43 (128K Flash) and ditch the external serial EEPROM.

Recently I created an Arduino 'sketch' (program) that included the firmware image for a PIC 16F18877 project as a constant ROM array as well as the LVP (Low Voltage Programming) drivers to actually program the image into the PIC. It was a relatively simple way for someone to build a version of Karen Orton's 2007 PICL/NIBL computer (an SC/MP emulator plus National Semiconductor's 4K NIBL BASIC) using a relatively inexpensive Arduino Nano clone instead of investing in an expensive PIC programmer for what might otherwise be a "one off" project. Check out the simple wiring diagram below. Anyway, you might consider something similar to 'burn' the 8-pin serial EEPROM.

Cheers...

[GARTHWILSON]

Michael wrote:

GARTHWILSON wrote:

It uses a PIC16 microcontroller.  I plan to make it available to others.  I just have to figure out some details of how to do that; for example, many users won't initially have any way to put the data in the serial EEPROM.

Which PIC are you using?  How much EEPROM/Flash storage do you need?  If it's a relatively modest amount, you might consider using a 20-pin 18F16Q40 (64K Flash) or a 28-pin 18F27Q43 (128K Flash) and ditch the external serial EEPROM.

It's a 16F72, partly because I have a lot of them from earlier projects.  I'm sure many other variations with 28 pins could drop into the same spot.  Part of the idea was to be able to quickly swap out the EEPROM if desired.  The 16F72 is not the cheapest around, partly because it has the A/D converter which I'm not using for this; but I tentatively plan to provide 24C256 I2C-6 EEPROM modules too, 32KB, and I can get the EEPROMs really cheap in quantity, and I use them for other things too.  [Edit, 7/28/22: The I2C-6 EEPROM module is on the front page of my site now, and there's a link to the data sheet there.]  This particular project might never use even half a KB.

How much EEPROM you need depends on how much you want to load.  Early bootload routines will probably be pretty simple, partly because of the chicken-and-egg situation regarding how to develop boot-up code for a computer that has never run yet.  Each record in the EEPROM has 9 bytes of overhead, and then there's the payload.  One of the bytes tells what kind of record it is.  You could have a record that's just text, to use as a volume label or explain something about the version.  The bootloader will just ignore that and go on to the next record.  The main kind of record is code to load in.  Let's say you wanted to load $E4 (228) bytes starting at address $300, and then the reset and IRQ vectors at $FFFC to $FFFF.  (228 bytes' length is an arbitrary guess, hopefully enough to load in the real OS.  It could be any quantity you want though, as long as it fits in the 32KB EEPROM.)  So you have 228+9=237 bytes for one record, and then 4+9=13 bytes for the record that gives these vectors.  There's no need to fill in all that space between $3E3 and $FFFC.  Another kind of record, which I have not implemented yet, is for other code for the '816 to execute in the process, like to put something in the display.  The bootloader won't be able to read it though, only write.

[tokafondo]

My two cents about what would be the contents of a small ROM that would be copied to RAM before booting is a small bootloader that would load the rest of the code from a storage device to a fixed location and then jump there. That way the use would not need to update the ROM itself but the contents of the storage device.

[GARTHWILSON]

tokafondo wrote:

My two cents about what would be the contents of a small ROM that would be copied to RAM before booting is a small bootloader that would load the rest of the code from a storage device to a fixed location and then jump there. That way the use would not need to update the ROM itself but the contents of the storage device.

Yes; that's exactly the idea.