Page 1 of 1
We're soliciting requests for 65xx info to add to the site.
Posted: Mon May 06, 2019 5:05 am
by GARTHWILSON
Bruce suggested having a wish list for 6502 technical information you'd like to see added to the non-forum part of the site. Feel free to write up wishes. (Mike has already accumulated a voluminous collection; so do make sure that the info you're wishing for is not already there.) You don't necessarily have to have a particular project in mind. Just put the wishes here, with minor discussion. This is not the place for lengthy discussions about each subject or projects you have in mind. Please use or start other topics for those. Thanks.
Re: We're soliciting requests for 65xx info to add to the si
Posted: Tue May 07, 2019 3:04 am
by floobydust
I've recently looked through the documents and code areas of the site. There is a lot of info there, much of it very old, as would be the case for the NMOS 6502. One thing I don't find a lot of are code examples that leverage the additional CMOS instructions that were added later (WD65C02S). I would also note that even the Eyes and Lichty Programming manual only mention some of the later added opcodes under the Rockwell version in the appendix, but not for the WDC version. These were added later to the WDC part.
Perhaps some code examples on using some of these newer opcodes and addressing modes would be useful. I've used many of them in my recent projects and they have proven very useful. Perhaps I'm being a bit narrow-minded on this, but I think it's worth updating or adding new code examples that use the newer CMOS instructions and show the benefit they provide.
Just my $0.02
Re: We're soliciting requests for 65xx info to add to the si
Posted: Tue May 07, 2019 5:35 am
by barrym95838
Yeah, I remember being impressed by Ross Archer's improvement to PRIMM
here, and devised a 65c02 version that doesn't trash Y and is even shorter:
Code: Select all
DPL = $fd
DPH = $fe
primm:
pla ; get low part of (string address-1)
sta DPL
pla ; get high part of (string address-1)
sta DPH
bra primm3
primm2:
jsr COUT ; output a string char
primm3:
inc DPL ; advance the string pointer
bne primm4
inc DPH
primm4:
lda (DPL) ; get string char
bne primm2 ; output and continue if not NUL
lda DPH
pha
lda DPL
pha
rts ; proceed at code following the NUL
P.S. I found another one for those who don't mind trashing y, in only 25 bytes:
Code: Select all
DPL = $fd
DPH = $fe
primm:
ply ; get low part of string address -1
pla ; get high part of string address -1
sta DPH
stz DPL
bra primm3
primm2:
jsr COUT ; output a string char
primm3:
iny ; advance the string pointer
bne primm4
inc DPH
primm4:
lda (DPL),y ; get string char
bne primm2 ; output and continue if not NUL
lda DPH
pha
phy
rts ; proceed at code following the NUL
Re: We're soliciting requests for 65xx info to add to the si
Posted: Tue May 07, 2019 1:40 pm
by floobydust
I also like using the additional instructions introduced with the Rockwell R65C02 (and later included with the W65C02):
RMBx - Reset a memory bit to zero in a page zero location
SMBx - Set a memory bit to one in a page zero location
BBRx - Branch on a memory bit reset to zero in a page zero location
BBSx - Branch on a memory bit set to one in a page zero location
note: x = 0-7
In a lot of older coding examples, a page zero location would be used as a flag byte for a specific routine, and checking for it being $00 or $FF, then branching accordingly. The newer instructions allow you to leverage a single page zero byte as eight separate flag bits. Much more efficient use of a single page zero location.
A simple example from my monitor code follows. Granted, this only saves a single byte of ROM space versus separate routines, but sometimes saving that one byte really helps
Code: Select all
;[CNTL-R] Reset System command: Resets system by calling Coldstart routine. Page zero is
; cleared, vectors and config data re-initialized from ROM. All I/O devices are reset from
; initial ROM parameters. Monitor cold start is entered.
SYS_RST LDA #$20 ;Get msg "Reset System"
SMB0 CMDFLAG ;Set bit0 of command flag
BRA RST_ONLY ;Branch below and handle reset
;
;[CNTL-Z] Zero command: zero RAM from $0100-$7FFF and Reset
ZERO LDA #$1F ;Get msg "Zero RAM/Reset System"
RST_ONLY JSR PROMPT ;Send to terminal
JSR CONTINUE ;Prompt for Continue
BBS0 CMDFLAG,DO_COLD ;Branch if reset only
SEI ;Disable IRQs
LDA #$01 ;Initialize address pointer to $0100
STA $01 ;Store to pointer high byte
STZ $00 ;Zero address low byte
DEC A ;LDA #$00
ZEROLOOP STA ($00) ;Write $00 to current address
INC $00 ;Increment address pointer
BNE ZEROLOOP ;Loop back until done
INC $01 ;Increment page
BPL ZEROLOOP ;Loop back IF address pointer < $8000
DO_COLD JMP B_COLDSTRT ;Jump to coldstart vector
;
Re: We're soliciting requests for 65xx info to add to the si
Posted: Tue May 07, 2019 5:31 pm
by Mike Naberezny
Bruce
suggested having a wish list for 6502 technical information you'd like to see added to the non-forum part of the site.
I would like to add
datasheets for all known 6502-like microcontrollers. The Renesas/Mitsubishi 740 series and Generalplus/Sunplus chips come to mind. I recently added a
Mitsubishi section with one datasheet for a chip that I worked with. There are many more chips. The part numbers need to be identified and the datasheets collected. There are probably many datasheets online already at the manufacturers' websites and other sources. I would appreciate any help rounding them up.
Re: We're soliciting requests for 65xx info to add to the si
Posted: Fri May 10, 2019 3:13 am
by Dr Jefyll
As a further comment regarding datasheets, I think it would be helpful to add an index that lists the chips according to the generic number (rather than by manufacturer). For example several companies make a 6522, and it would handy to become aware of all those 6522's (and 65C22's) without going through 10 or 12 manufacturer folders.
BTW I have a 65816 datasheet from CMD I'd be happy to contribute (possibly one from VLSI Technology, too); also a copy of the Apple IIgs Hardware Manual which extensively describes the '816 in Chapter 10. These could be useful for cross-checking, given that WDC's '816 doc isn't the greatest.
-- Jeff
Re: We're soliciting requests for 65xx info to add to the si
Posted: Fri May 10, 2019 6:33 am
by Mike Naberezny
As a further comment regarding datasheets, I think it would be helpful to add an index that lists the chips according to the generic number (rather than by manufacturer). For example several companies make a 6522, and it would handy to become aware of all those 6522's (and 65C22's) without going through 10 or 12 manufacturer folders.
I agree. I have wanted this myself at times.
BTW I have a 65816 datasheet from CMD I'd be happy to contribute (possibly one from VLSI Technology, too); also a copy of the Apple IIgs Hardware Manual which extensively describes the '816 in Chapter 10. These could be useful for cross-checking, given that WDC's '816 doc isn't the greatest.
Thank you and I would be happy to add them to the archive. Please send me a private message or email and we'll work out the details. If you would like to scan them, then I'll just post your scans. If you would like to mail me the original paper, I will scan and return them (unless you tell me to keep them).
Re: We're soliciting requests for 65xx info to add to the si
Posted: Mon May 13, 2019 3:29 am
by dclxvi
This isn't really a personal wish list, but I can think of a number of projects that might be of general interest, and might help fill in a few of the (minor) blanks. In no particular order:
- 65C816 test suite - a resonably complete suite will be large, but this can be developed and released incrementally. A few instruction and addressing mode tests are better than nothing.
- Compression: RLE - this might make a nice introduction to compression tutorial and both the compressor and decompressor can be easily implemented on a 8-bit micro with 16-bit address bus, and are short and easy to understand.
- Disassembly: Apple I BASIC and/or Apple II Integer BASIC - a fully commented disassembly listing with meaningful label names, notes on program and variable storage, (data) stack usage, zero page usage, and syntax table tokens would be educational and useful for anyone interesting porting (or patching) it. Such disassemblies exist for Microsoft BASICs (e.g. S-C DocuMentor for Applesoft), but the disassemblies for Apple I and Integer BASIC are a nice start, but not at that level of detail.
- Disassembly: KIM Focal - likewise for KIM focal; there are disassemblies, but not at such a high level of detail
- Disassembly: Tiny BASIC - likewise for Tiny BASIC
- Documentation: 65C02 instructions cycle-by-cycle behavior, including guaranteed NOPs - the equivalent to the cycle-by-cycle behavior of Table 5-7 in the (November 9, 2019) 65C816 Datasheet is in the March 2000 data sheet here at 6502.org (that part can be solved with a simple web page link), but it might also be useful to have the cycle-by-cycle behavior of the guaranteed NOPs (not all are 1 cycle).
- Documentation: NMOS 6502 undocumented opcodes - there are several places on the web where you can find this information, but it might be nice to compile the various names that have been given to these opcodes in a single place. Furthermore, now that Visual 6502 exists, it should be possible to document the cycle-by-cycle behavior (like Table 5-7) for all of these instructions. (Cycle-by-cycle behavior for the documented instruction is in the Synertek Programming Manual.)
- EhBASIC: replace LAB_XXXX labels with meaningful names - its one thing to have LAB_XXXX (where XXXX is a 4 digit hex number) for (the equivalent of) local labels, but there are many instances of LAB_XXXX for subroutines (e.g. copying FAC1 to FAC2) and mathematical constants. An awk (or whatever) script that replaces these labels with more meaningful ones would be nice. You don't even have to think of label names, you can use the ones in S-C DocuMentor.
- EhBASIC: document zero page usage - a document describing the zero page usage (how many bytes a zero page variable uses, and what it's used for) might be helpful when you have zero page conflicts. This is trickier than it looks; for example, Adatal looks like it only uses 2 bytes, and it does in some cases, but it's also used to temporarily store a floating point value and in those cases it uses 4 bytes, and you need to be careful whats in the 2 bytes after Adatah.
- Math: The standard unsigned multiplication and division algorithm - a document that describes the standard shift-and-add (for multiplication) or shift-and-subtract (for division) algorithms might be helpful for beginners. Nothing fancy, no optimization tricks, just the basic routines, and how and why they work. It's not hard to understand, but I suspect those of us who are more experienced with the 6502 tend to take this for granted, and I wonder how clear it is to beginners. Signed multiplication and division could be a sequel tutorial.
- Math: Fast multiplication: AB = ((A+B)^2 - (A-B)^2) / 4 -- it might be nice to have a tutorial that explains this multiplication technique, along with a routine that generates the tables of squares, and a unit test.
- Sort: Heapsort implementation - the repository has a Shellsort routine with a O(N^(3/2)) implementation. A Heapsort routine is O(N log N) worst case, is suitable for a 8-bit processor with 16-bit address space (it's in place), and is relatively easy to understand.
- 65C816 BASIC - this is obviously a pretty big project, and there's no guarantee that it would be all that popular, but I suspect there's at least a few people who'd be interested in a BASIC that was written for the 65C816 (e.g. allowing arrays larger than 64k), and not just a 6502 BASIC running in emulation mode or 8-bit native mode.
Re: We're soliciting requests for 65xx info to add to the si
Posted: Tue May 14, 2019 12:24 am
by Windfall
65C816 BASIC - this is obviously a pretty big project, and there's no guarantee that it would be all that popular, but I suspect there's at least a few people who'd be interested in a BASIC that was written for the 65C816 (e.g. allowing arrays larger than 64k), and not just a 6502 BASIC running in emulation mode or 8-bit native mode.
I've made something going in that general direction for
http://www.zeridajh.org/hardware/reco6502/index.htm. It's an existing 65C02 coded BASIC, but I changed it so that all program variables are stored in above-64KB memory and manipulated by '816 24-bit addressing.
Re: We're soliciting requests for 65xx info to add to the si
Posted: Tue May 14, 2019 12:51 am
by DerTrueForce
One thing I've noticed as I was looking for an alternative 65816 assembler was that there are a number of dead links on the site. It'd probably be a good idea to remove them, and perhaps keep a note of them, so they can be restored if a new link comes up later.
Re: We're soliciting requests for 65xx info to add to the si
Posted: Tue May 14, 2019 1:40 am
by Mike Naberezny
One thing I've noticed as I was looking for an alternative 65816 assembler was that there are a number of dead links on the site. It'd probably be a good idea to remove them, and perhaps keep a note of them, so they can be restored if a new link comes up later.
Please tell me specifically which links are broken and I will fix or remove them.
Re: We're soliciting requests for 65xx info to add to the si
Posted: Tue May 14, 2019 1:45 am
by Chromatix
Routines and/or a complete program and/or a complete minimalist testbed with schematic and ROM, to positively identify an unknown/suspect 6502-family CPU, since there are so many fakes out there.
At minimum it should distinguish NMOS from CMOS, 65816 from 6502, whether zero-page bit-manipulation opcodes work, and check whether Decimal mode and ROR/ROL work correctly. Preliminary research suggests all these should be reasonably straightforward. There may also be ways to see whether WAI and STP are implemented; WAI can be tested, for example, with the aid of a cycle-accurate counter with IRQ on timeout, as provided by the 6522 and some of the better UARTs.
Optional: check also for common simulator mistakes (non-standard Decimal behaviour, for instance, or incorrectly combining CMOS/NMOS characteristics); report everything in a human-readable way (not like Klaus' otherwise excellent test suite, where you have to observe at which address it goes into an infinite loop); check for rare derivatives of the 6502 family with extra and/or missing features.
A hardware solution for this could forego setting up a standard SBC-like machine in favour of a minimal breadboard hookup to a Raspberry Pi. Or it could be a basic, cheap, robust SBC design with just the ROM space and I/O handled by a Raspberry Pi with set/reset wait-states (giving the Pi as much time as it wants to respond). Or it could be a complete SBC with a UART (or a 6522 and a built-in display) and a pre-burned ROM. The point is to be as foolproof as is practical in a hobbyist context, where a newbie hobbyist might need to test his only/first CPU without first having assembled his own SBC.
Implementation details to another thread…
Re: We're soliciting requests for 65xx info to add to the si
Posted: Tue May 14, 2019 2:12 am
by thedrip
More of a project request than documentation. A simulator with common hardware options. Define a ram address space, 6551 or 6850 at your configured address, 6522 and other common chips.
Basically simulate a basic an sbc so we can develop code or test ported code more easily.
Edit: 6 months later I stumbled on Symon which does most of what I was looking for.
https://github.com/sethm/symon
Re: We're soliciting requests for 65xx info to add to the si
Posted: Tue May 21, 2019 1:08 am
by handyandy
Here
https://www.fadden.com/apple2/hdc/index.html is a 12 course tutorial on data compression. Code is C and 65816 native assembly.
Cheers,
Andy
Re: We're soliciting requests for 65xx info to add to the si
Posted: Tue May 21, 2019 2:00 am
by barrym95838
Those write-ups are very nicely done, Andy!