(Fwd) 65816->6502

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

(Fwd) 65816->6502

Ruud
Hallo allemaal,


Maybe interesting for some of you?


------- Forwarded message follows -------
Date sent: Sun, 11 Mar 2018 14:21:39 +0000 (UTC)
From: Andy Werner <[hidden email]>
Send reply to: Andy Werner <[hidden email]>
To: "[hidden email]" <[hidden email]>
Subject: 65816->6502


Hi Ruud,

I saw this morning:

http://www.a2heaven.com/webshop/index.php?rt=product/product&product
_id=151

Seems affordable.

Cheers!
Andy

------- End of forwarded message -------



--
   
Kind regards / Met vriendelijke groet, Ruud Baltissen
www.Baltissen.org







Reply | Threaded
Open this post in threaded view
|

Re: (Fwd) 65816->6502

Anders Carlsson
Ruud wrote:

> Maybe interesting for some of you?
>
> http://www.a2heaven.com/webshop/index.php?rt=product/product&product_id=151

Availability: Out of Stock, but perhaps that is only temporarily?

Suitable for a PET, VIC-20 or 1541, I presume, though the listing mainly
caters for Apple II.

Best regards

Anders Carlsson



Reply | Threaded
Open this post in threaded view
|

Re: (Fwd) 65816->6502

David Wood-2
The seller specializes in apple II goods, and his items go in and out of stock periodically.  Keep an eye on the site.

Disclaimer- Ive not ordered from him before

On Tue, Mar 13, 2018 at 3:25 PM, Anders Carlsson <[hidden email]> wrote:
Ruud wrote:

Maybe interesting for some of you?

http://www.a2heaven.com/webshop/index.php?rt=product/product&product_id=151

Availability: Out of Stock, but perhaps that is only temporarily?

Suitable for a PET, VIC-20 or 1541, I presume, though the listing mainly caters for Apple II.

Best regards

Anders Carlsson




Reply | Threaded
Open this post in threaded view
|

Re: (Fwd) 65816->6502

Gerrit Heitsch
In reply to this post by Anders Carlsson
On 03/13/2018 08:25 PM, Anders Carlsson wrote:

> Ruud wrote:
>
>> Maybe interesting for some of you?
>>
>> http://www.a2heaven.com/webshop/index.php?rt=product/product&product_id=151 
>>
>
> Availability: Out of Stock, but perhaps that is only temporarily?
>
> Suitable for a PET, VIC-20 or 1541, I presume, though the listing mainly
> caters for Apple II.

A 1541 would be a bad idea. Many speedloaders (parallel or serial) use
illegal opcodes and those will not work on a 65816.

In a 15xx drive, you want an NMOS-6502 if you want to be sure everything
works. Only exception is the 1551, there you want a 6510T.

  Gerrit


Reply | Threaded
Open this post in threaded view
|

Re: (Fwd) 65816->6502

MiaM
In reply to this post by Anders Carlsson
Den Tue, 13 Mar 2018 20:25:23 +0100 skrev Anders Carlsson
<[hidden email]>:

> Ruud wrote:
>
> > Maybe interesting for some of you?
> >
> > http://www.a2heaven.com/webshop/index.php?rt=product/product&product_id=151
>
> Availability: Out of Stock, but perhaps that is only temporarily?
>
> Suitable for a PET, VIC-20 or 1541, I presume, though the listing
> mainly caters for Apple II.

In other words it's probably not tested in anything else than an Apple
II.

Apple II afaik has a memory map where you really don't have much incent
to rearrange stuff to gain more continous ram. Those Apple II that
have more than 48k ram seem to be able to bank switch between ram and
rom so only a 4k $Cxxx block is always occupied by I/O and I/O related
ROMs. So a total of 60k ram can be accessed simultaneously by the CPU.
(The reason for having 64k and also advertising it as 64k is probably
the Z80 add-ons for running CP/M).

http://www.kreativekorp.com/miscpages/a2info/memorymap.shtml

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. Also ram on a 65816 board makes
it possible to run code on the 65816 far faster.

But all this stuff would of course add to cost.

Btw has anyone tried what happens if you replace char rom (as seen from
the CPU) with RAM? Will the KERNAL ram test/detect routines mess up
with I/O?

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

Reply | Threaded
Open this post in threaded view
|

RE: (Fwd) 65816->6502

Baltissen, GJPAA (Ruud)
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.


Met vriendelijke groet / With kind regards, Ruud Baltissen

www.Baltissen.org




De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617


Reply | Threaded
Open this post in threaded view
|

Re: (Fwd) 65816->6502

MiaM
Den Wed, 14 Mar 2018 07:35:13 +0000 skrev "Baltissen, GJPAA (Ruud)"
<[hidden email]>:

> 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.

Reply | Threaded
Open this post in threaded view
|

Re: (Fwd) 65816->6502

André Fachat

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 <[hidden email]>:

Den Wed, 14 Mar 2018 07:35:13 +0000 skrev "Baltissen, GJPAA (Ruud)"
<[hidden email]>:
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.