Re: (Fwd) 65816->6502

Mia you could look at my PET 10MHz board and just modify the address 
selection to pass through VIC20 I/O instead of PET I/O.

Regards
André

Am 15. März 2018 00:17:03 schrieb Mia Magnusson <mia@plea.se>:

Den Wed, 14 Mar 2018 07:35:13 +0000 skrev "Baltissen, GJPAA (Ruud)"
<ruud.baltissen@apg.nl>:
Halo allemaal,


Mia schreef:
On PET (except 8096/8296), VIC-20 and 1541, it's as we all know not
that nice. Therefore IMHO a 65816 add-on for those computers should
preferable also contain ram and a mechanism to bank switch between
that ram and the computers built in stuff.

IMHO it isn't that hard. I expanded a VIC-20 with an ISA interface so
I could use an old RAM expansion card as extra memory. This card is
equipped with 128 KB SRAMs so no problems with refresh. The interface
was made in a quick and dirty way by piggybacking the ICs on top of
the existing ones of the VIC-20. It worked more or less because I
found out I made a mistake due to the lack of knowledge at that time:
RDY did not work as I expected. Even if RDY is negated, the 65816
keeps on outputting address lines A16..23 on the data bus. I did find
a solution for it at the end but didn't implement it here because of
the work involved.

What is needed:
- a 573 for creating the address lines A16..23
- two 541s for generating the address bus towards the original system
+ pull-up resistors
- one 125 gate for the R/W line + pull-up resistor
- a 245 between the 65816 and the original system
- a 688 for detecting if bank 0  = original system is accessed
- four NAND gates = one 00 for handling RDY
- some glue logic

The idea is simple: as long as the 65816 accesses the original
system, the 541s forward the address lines A0..15 towards it.
Accessing any other bank will tri-state the address lines and R/W
line. The resistors will make the original system think that address
$FFFF needs to be read. Save enough IMHO. The 245 makes sure that the
outputted data does not reach the 65816. I'll see what is on
schematic and I will upload it to my site.

If this would be acting as memory in BLOCK 3, it would be easy to just
pull A15 low forcing the adress to be $7FFF, then you shouldn't have to
worry about the data bus. This way it would be easier to make most of
it a cartridge, with a short cable to an adapter board in the CPU
socket.

P.S. A VIC-20 kind of screams that it wants to be modified in other
ways. The VIC chip can actually access 16k adress space, but even with
the "8k internal" mod it still only sees 8k ram and 4k char rom. In
some semi-distant future when I've actually repaired my VIC 20 CR
boards (which are in a bad state due to someone pushing in 9V AC and 5C
DC onto the IEC socket; in one of them the inside of the bottom case
plastics is a bit melted from the heat from the burnt 7406...), I'm
planning on replacing both 6116 and two 2114 SRAM's with a 62256 32k
SRAM and add some more decoding, making the VIC chip able to see
atleast 12k ram and probably with some logic making that 12k atleast
partially reside in some other place than the first 1k. Kind of silly
that the zero page and the stack is part of what VIC can use.

But with a 65816 CPU you would really want to turn things the other way
around, create a local bus with the CPU and some RAM that can run at
maximum speed, and make the VIC steal *fast* cycles from that circuit.
As VIC only reads, never writes, each read can be made really short by
latching the output from the RAM. The same goes for for example the B
series where the CRTC hardware could do really short accesses to faster
memory if it had a faster CPU. Of course this is also true for VIC-II
based machines. For VIC and VIC-II and with fast enough ram, color ram
could be replaced by reads from main memory.


--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.