6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu Nov 21, 2024 9:26 pm

All times are UTC




Post new topic Reply to topic  [ 64 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Mon Dec 27, 2021 2:42 am 
Offline

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1117
Location: Albuquerque NM USA
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


Attachments:
ZG6502 Monitor rev0.1.jpg
ZG6502 Monitor rev0.1.jpg [ 120.09 KiB | Viewed 3425 times ]
Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 29, 2021 2:50 am 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
From ZG65Mon.lst:
Code:
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:
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:
    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

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Last edited by barrym95838 on Wed Dec 29, 2021 3:21 am, edited 2 times in total.

Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 29, 2021 3:10 am 
Offline

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1117
Location: Albuquerque NM USA
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.


Attachments:
ZG6502_r0.png
ZG6502_r0.png [ 57.53 KiB | Viewed 3370 times ]


Last edited by plasmo on Wed Dec 29, 2021 3:31 am, edited 1 time in total.
Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 29, 2021 3:31 am 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
Ah, got it. But then is it okay to jmp *+3-$8000 so soon?

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 29, 2021 3:36 am 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
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.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 29, 2021 3:44 am 
Offline

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1117
Location: Albuquerque NM USA
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


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 10, 2022 4:11 pm 
Offline
User avatar

Joined: Tue Aug 11, 2020 3:45 am
Posts: 311
Location: A magnetic field
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.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 10, 2022 5:33 pm 
Offline

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1117
Location: Albuquerque NM USA
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


Attachments:
ZG6502_r0_F.jpg
ZG6502_r0_F.jpg [ 1.11 MiB | Viewed 3301 times ]
Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 27, 2022 2:24 pm 
Offline
User avatar

Joined: Tue Aug 11, 2020 3:45 am
Posts: 311
Location: A magnetic field
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.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!


Top
 Profile  
Reply with quote  
PostPosted: Sun Apr 17, 2022 2:27 am 
Offline

Joined: Sat Apr 11, 2020 7:28 pm
Posts: 344
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.


Top
 Profile  
Reply with quote  
PostPosted: Sun Apr 17, 2022 2:50 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
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.


Attachments:
Bootloader2.jpg
Bootloader2.jpg [ 150.85 KiB | Viewed 3153 times ]

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Top
 Profile  
Reply with quote  
PostPosted: Sun Apr 17, 2022 4:38 am 
Offline
User avatar

Joined: Wed Feb 13, 2013 1:38 pm
Posts: 589
Location: Michigan, USA
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...


Attachments:
PICL Programmer Hack.jpg
PICL Programmer Hack.jpg [ 157.96 KiB | Viewed 3132 times ]
PICL Programmer.png
PICL Programmer.png [ 242.94 KiB | Viewed 3149 times ]


Last edited by Michael on Sun Apr 17, 2022 2:27 pm, edited 1 time in total.
Top
 Profile  
Reply with quote  
PostPosted: Sun Apr 17, 2022 6:03 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Sun May 01, 2022 2:49 am 
Offline

Joined: Sat Apr 11, 2020 7:28 pm
Posts: 344
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.


Top
 Profile  
Reply with quote  
PostPosted: Sun May 01, 2022 4:54 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 64 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 38 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: