Posted By
gpz
on 2015-12-19
16:58:31
|  unused I/O location for debug purposes
i have recently started with (finally!) adding some kind of automatic testing to VICE starting with the c64 emulators... and would of course like to do the same for plus4 too (if only to kick tlr out of his sleep period =))
what i am looking for is an "unused" I/O location in the plus4 memory map...
- it must not conflict with any of the plus4 regular chips (obviously). it may however be implemented as an overlay to a register that has no significant side effects when written to (see c64 note(*))
- it must not change with the different plus4 configurations/memory maps
- ideally it does not conflict with any "common" expansion
- a bonus would be if the write to that location can be "seen" also at the expansion port. this isn't strictly necessary, but would be nice just in case someone would ever knock up such debug mechanism in a real cartridge.
(*) c64 note: for the C64 we have picked $d7ff - this is normally a mirror of the SID register $1f, which is unused.
if somehow who is more into the plus4 than me could give some suggestions, that would be great 
|
|
Posted By
Csabo
on 2015-12-19
19:33:51
| Re: unused I/O location for debug purposes
Hi there,
I'm a bit unclear on what you ultimately want to do, is this something for emulators only? If so, I think $FF20-$FF3D are not used (and cannot be used) for anything, so that might work.
|
|
Posted By
gpz
on 2015-12-19
22:59:52
| Re: unused I/O location for debug purposes
ok, so what you say could be used as a last resort.
no, ideally it shouldnt be emulator only - although its an option. the main requirement is that writing to that location never has any side effects, even on real hardware (it must be possible to run test programs unmodified on real hardware). as a bonus, it would be "nice" if the write to that location can also be "seen" at the expansion port so that in theory one could build a real cartridge that does what the debug stuff in the emulator does. (ultimatively i want to do that.... because the testsuite must be tested too )
|
|
Posted By
siz
on 2015-12-20
01:43:02
| Re: unused I/O location for debug purposes
Long time ago Solder created a list of the used I/O addresses including custom hardware. His site does not seem to work now (www.solder-synergy.net) but I have it mirrored (offline). The contents of the file ioarea.txt:
-------------------------------------------
Overview for the used adresses in i/o-area. Hardware-developer: This is no dictate for you. But for compatibility you should use free adresses. Mail me the adress from your hardware. I will add it to this list. solder@gmx.net
$fd00-$feff plus/4-i/o-area
$fd00-$fd0f ACIA-chip (6551/8551)
$fd00-$fd03 effective range for ACIA
$fd03-$fd0f mirrors of $fd00-$fd03
$fd10-$fd1f Userport 6529B-chip (original)
$fd10 effective adress for 6529B (original)
$fd10-$fd1f mirrors of $fd10 (original)
$fd10-$fd1f Userport-area (plus/4 with expansion)
$fd10 6529B-chip from userport
$fd11-$fd12 Centronics-printerport
$fd13-$fd14 Low-/high-switching for OS96
$fd15 Register for CSORY-RAM-expansion
$fd16 Register for Hannes-RAM-expansion
$fd17 Register for EPROM-/sRAM-expansion
$fd18-$fd1f free (best for internal expansion)
$fd20-$fd2f used by different hardware, decoded by PLA (pin 18)
$fd30-$fd3f 6529B for keyboard
$fd30 effective adress for this 6529B
$fd31-$fd3f mirrors of $fd30
$fd40-$fd5f SID-card, area for SID-chip
$fd40-$fd5d SID-chip
$fd5e DAC on digiblaster add-on
$fd5f ADC on digiblaster add-on
$fd60-$fd7f Area for expansion-userport
$fd60-$fd63 ACIA on card 1
$fd64-$fd67 ACIA on card 2
$fd68-$fd6b ACIA on card 3
$fd6c-$fd6f ACIA on card 4
$fd70-$fd73 6529B-emulation on card 1
$fd70 effective adress for 6529B-emulation
$fd71-$fd73 mirrors of $fd70
$fd74-$fd77 6529B-emulation on card 2
$fd74 effective adress for 6529B-emulation
$fd75-$fd77 mirrors of $fd74
$fd78-$fd7b 6529B-emulation on card 3
$fd78 effective adress for 6529B-emulation
$fd79-$fd7b mirrors of $fd78
$fd7c-$fd7f 6529B-emulation on card 4
$fd7c effective adress for 6529B-emulation
$fd7d-$fd7f mirrors of $fd7c
$fd80-$fd8f Joyport on SID-card
$fd80 effective adress for joyport
$fd81-$fd8f mirrors of $fd80
$fd90-$fdcf free
$fdd0-$fddf Area for ROM-banking
$fde0-$fde1 MIDI-interface
$fde2-$fdef free
$fdf0-$fdfd free
$fdfe Register on EPROM-card
$fdff Register on sRAM-card
$fe00-$fe7f free (best usage for a RAM-drive...)
$fe80-$fe9f SID-card, mirror from $fd40... for hungarian-compatibility
$fe80-$fe9d SID-chip
$fe9e DAC on digiblaster add-on
$fe9f ADC on digiblaster add-on
$fea0-$febf free (?)
$fec0-$fecf Floppy 1551, device 9
$fed0-$feef free (?)
$fef0-$feff Floppy 1551, device 8
note: please don't use mirror-adresses in your programs. Perhaps a mirror-
adress is decoded better later (like $fd10-$fd1f). Your programs will not
work then.
|
|
Posted By
gerliczer
on 2015-12-20
06:31:08
| Re: unused I/O location for debug purposes
What Csabo written earlier may not be completely true. I have some hazy memory about a program I came across ages ago, that used the empty space in the TED register map as RAM. I don't know where the memory comes from or what the program was. I can be very wrong. Actually, somebody with access to a real machine should check it, if it's not too much work.
|
|
Posted By
MikeZ
on 2015-12-20
08:36:07
 | Re: unused I/O location for debug purposes
The reason for the mirror images is that the pla doesn't decode the 4 LSBs of the address buss. In sends a chip select to the ACIA when it reads FD0-. To use the addresses FD04 to FD1F you must decode the 4 LSBs on the address buss when the ACIA is active. I did this in 1987 by using a 16 to 4 decoder chip. It got its chip secect from the PLA's FD0 chip select. The 4 pin side was connected to the 4 LSBs of the address buss and 12 of the 16 outout pins corresponding to FD04 - FD1F were each connected to an additional 6529 I/O port. That was my application and it worked.
|
|
Posted By
Csabo
on 2015-12-20
16:23:29
| Re: unused I/O location for debug purposes
You're right gerliczer, it seems $FF20-$FF3D *is* usable when RAM is paged in (just as $FF40 and above - that's pretty common actually). But regardless, the correct answer is what siz said above, and of the bytes marked as free should be good.
|
|
Posted By
SVS
on 2015-12-21
06:20:57
 | Re: unused I/O location for debug purposes
I did perform some tests on a real Plus4.
The memory not used by TED, $FF20...$FF1D is free usable RAM. I mean that you can write there your values and they remain without been affected by O.S. or by TED.
On the ROM these locations are filled by $6A $00 $6A $00 ...
Referring to the RAM area from $FF40 to $FFFF it is freely available in my opinion. From what I remember I "should" have used it in my old SVS-OS for the RamDisk utility. The same addresses on the ROM show garbage with a possible text "WBUE9101" whatever it means.
Note that I have installed OS96 ROMs.
|
|
Posted By
gpz
on 2015-12-21
07:40:10
| Re: unused I/O location for debug purposes
is the complete range available at the expansion port? or what range is?
|
|
Posted By
siz
on 2015-12-21
08:15:46
| Re: unused I/O location for debug purposes
You have to do your own address decoding outside the computer. (Except for the expansion ROM lines) Basically you catch all write attempts in the 64K address range.
For I/O purposes the $fd00-$feff range is reserved so they are safe for read. And you have to be prepared for other expansions present which are mentioned above.
You can use ROM expansions also as does BSZ's custom extension used for the Evo Lution demo: it maps RAM in the place of the ROM as video memory. In this case your write attempts are processed by your expansion AND the underlying RAM too.
And also there is the possibility which is used by the 64K RAM expansions which "replaces" the internal RAM (or more like overrides) with an external one. I'm still not sure how does that work.
But for your debugging purposes $fe00-$fe7f range seems to be safe to use.
|
|
Posted By
Blacky Stardust
on 2015-12-24
14:47:16
| Re: unused I/O location for debug purposes
$fd20-$fd2f is used in the V364 for the speech chip.
However the range for the speech chip itself is $fd20-$fd22, does any-1 know if the chip is mirrored through the rest of the range or if there is some kind of ram present ??
|
|
