RE: Theorizing: cloning CBM electronics with modern technology.

Jim schreef:
Correct.  A 6502/6522/ROM/RAM/SD card combo, in my opinion, doesn't offer the community more than the sd2iec. sd2iec fails with code running on the drive CPU, but even if you added the CPU, the code will still fail since it would assume a floppy mech.

I completely disagree with this statement. With my 1541IDE project I ran into two types of problems:
- programs, mostly speed loaders, that manipulate the 6522s directly and don't use the ROM to load or write data
- programs that use parts of the ROM for their own purposes
In the first case I couldn't do anything. Period. My ROM intercepts the original routines at the very last moment, the moment the hardware would be accessed, and then executes my own routines that handle the HDD. Its is more or less the same problem that IDE64 cartridge ran into. Note: I noticed programs that altered variables to make stepping faster, for example. But that had no effect on my routines because they didn't use it.
In the second case the solution was to save my routines in the range $8000-$BFFF and there where needed to replace original code with JMPs to that code. I ran into this problem when inserting the KCS Power cartridge.

OTOH, Jiffy DOS worked without any problem. Using SD2IEC with an ATmega means that you have to write the code that handles the JD protocol yourself. Whether I connect a SD card directly to a 6522 or use a uC, I would only have to write new routines for the $8000-$BFFF part.
EXOS V3 loads code into the 1541 and that won't work well with a SD2IEC. But it worked w/o problems with 1541IDE.
Why do JD and EXOS work fine? They only affect the communication protocol (AFAIK) and don't mess with the 6522s .

Gerrit Heitsch schreef:
It also means that it emulates the mechanic 100%, any floppy speeder or code loaded into the 1541 should still work with it and that was the idea behind it. Also most copy protections shouldn't be able to detect anything off. Weak bits might be a problem though.

Here I disagree as well. As said above, the moment a programs uses its own code to access the FDD, which isn't present anymore, the uC will be ignored and nothing happens. If a copy protection manipulates the 6522 by changing the track directly, the uC won't notice and you are in trouble. And what about using half-tracks for storing data? Will the uC notice that as well?

I rest my case.


With kind regards / Met vriendelijke groet, Ruud Baltissen

http://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