-
Hmm, bei mir nicht !
Da ich das jetzt nicht testen kann (icch habe eine DTV 3 Version), versuch mal, mit den Verzögerungen rumzuspielen.
Ab 0xff00 liegen nach dem Entpacken ein paar "lda ($4b,x)" und ein abschließender "RTS".
Das ist die Zeitschleife, die ich dazu gepackt habe.
Änder da mal ein bischen mit rum (mal welche dazu, mal welche weg).
An dem Ergebnis bin ich sehr interessiert ...
P.S. : Am einfachsten ginge das, wenn Du die ungepackte Version mit dem "DTVMon"
reinlädst. Normal liegen die Daten leider an Adressen, wo der VIC etc. residiert.
-
i have done some other stuff now. look there !
Spiele mit DTV-Fix
-
So, das nächste Games ist fertig.
Einer meiner Lieblingsklassiker !
Ich habe die Version so umgebaut, daß man mit den Knöpfen A-D
alles einstellen kann.
Zusätzlich wird der Joystick in Port 1 nur gebraucht, wenn
man den Zweispielermodus ausgewählt hat.
Viel Spaß !
-
OK, then I will have a look at "hypra-save". Or do you know a faster one ?
-
The "only basic" idea is better than nothing but not so good for games
that uses the normal disk functions (and I think out aim must be to replace them) if there
has modified the $dd00 lower 2 bits (for displaying a picture, for example).
So I looked for the code that stores at 0xdd00.
my idea is to modify the code BEFORE starting the fastloader with the current
setting of $dd00 lower two bits.
So I have build up a table where the $dd00 address is used with STA, STX and STY:
------------------------------------------------------------------
STA at address | value for store loaded
------------------------------------------------------------------
e48c | lda #03 at e48a
e61b | lda #03 at e619
e621 | lda #0b at e61f
e781 | lda #0b at e77f
e79a | ? (comment follows)
e7a7 | lda #03 at e7a5
------------------------------------------------------------------
STX at address | value for store loaded
------------------------------------------------------------------
e78b | ldx #03 at e77d
------------------------------------------------------------------
STY at address | value for store loaded
------------------------------------------------------------------
e641 | ldy #00 at e63f
------------------------------------------------------------------
now the comment (the other cases are trivial to modify):
the code for the store is the following (at e78e)
ldx #$04
lda $ff ; line marker
lsr $bd
ror
lsr $bd
ror
lsr
lsr
sta $dd00
dex
bne e790 ; jump to marked line
This must be the function (the only one ?) that sends data to the 1541.
I don't know how time critical this is. Maybe and "and #0x ; or #0x" can be inserted here ?
And what is the role of the byte in $ff ?
-
another possibiliy could be the following:
Let the code as it is (on 0xe000 to ffff with all its buffers)
This code is copied (via dma for faster transfer) to a free RAM area of the DTV
(maybe 0x1fa000).
then, when entering the loader, switch via bank switching 0x1fa000-01bffff to 0x00e000 to 0x00fffff. Then the code can run nearly unchanged.
The only thing to change is then the block copy, this can be made like you suggested via DMA to the place where the data has to load to.
by the way (because of the bad $dd00 handling):
Have you tested what happened if the lower two bits are switch to input via
$dd02 ?
-
I have done a little look at the fastloader.
It seems the it reads some coded data from the drive and stores
it at 0xfe00 and 0xff00 undecoded. Then the data is calculated to the "real" data at 0xfd00.
But the stuff synchronizing the C64 prozessor with the drives's processor is very confusing.
It seems that this stuff must be very cacle exact.
There seems to be some drive code at 0xe000 and the C64 code begins at 0xe406.
All stuff that is needed ends at 0xe900.
Is the stuff at the beginning ($e000) that it seems to be ?
When I look at it it looks like datas that are endcoded for the data transfer to the 1541,
to avoid encoding it on the fly ?
-
Works great. My version is history now ... 
-
some thoughts about the size of the fastloaders for DTV
before today I thought that the fastloaders to build into the kernal must be small because they have to fit in the space that we got from disabling the tape and rs232 routines. But this is not really true !
Instead of making them fit into the kernal, we can put it into a replacement Basic rom that is switched via $d101 in the time we are loading and saving to disk !
That offers additional 8K of ROM code. I think there is enough place for different fastloaders, too. Perhaps something like an autodetection detects if we have a 1541, 1581 and then select a special fastloader for the different drives.
The positive feature of that is that there is enough place to leave the DTV flash loader functions where they stay now !
Any opinions about that ?
-
Can you post this "25x turbo" or post a link so I can have a look to this also ?
-
I have tested a program called "hypra save". It seems to work on my DTV.
It was published in the old days from the 64er magazine. But with 6 Blocks I think it is to big to fit into a kernal containing a fast loader, too.
The fast loader of EXOS was one of the fastest loaderss I knew in these old days. Perhaps your loaders are faster, I don't know it.
I have also added a small fastloader from the same disk I had the hypra save from. But it is not very fast in comparison to the one in EXOS.
I knew that there was a kernal with hypra-load and hypra-save all together in a rom in these days but I could not find it in the internet now.
By the way : I have tried to disable the screen blanking of the EXOS rom and disables the bad lines of the DTV vie the corresponding extra DTV registers. The loader itself works, but they do some terrible thing with the lower 2 bits of $dd00 so the vice base was shifted elsewhere during loading.
-
That's my version of exos v3
I have mapped F7 to F2 (because sys 32768 make not a great sense for me)
I think there is no fast save in exos V3.
Here is the file
-
I have patched your version 0.5 to add the possibility to run alternate kernals.
On my DTV, I have added the EXOS V3 kernal to speed up loading from disk.
With this patch, a kernal can be flashed at 0x1fe000 and activated via boot menu.
(like the ROM switches on the real C64 that the most users had in the past)
Because of my patch is done really nasty, I think you can add this feature in some of your next releases of your DTVMON
Here is my little patch:
-
I have flashed all my favorite games and tools into the DTV with your tool, and because I run out of flash memory I have flashed a special version of the Turbo Assembler Professional on it at address 0x002000 (just behind the first character ROM but before the Basic- and Kernal-ROM.
It works fine there.
But now my question :
If I want to replace my version of the TMP, is the kernal ROM disabled by the flashtool ?
Because I am afraid that erasing the block 0 of the system will erase the RUNNING
Kernal too, than the flashtool craches, and then my DTV is unusable for me !
Please let me know.
-
So, jetzt habe ich noch mal für alle, die im dtv nicht flashen wollen (oder erst mal testen wollen) noch ne gepackte Version hier eingestellt.
-
IK+ habe ich jetzt mal gefixed.
Wahr n bischen schwierig, da das Timing im DTV wohl anders ist als im normalen C64.
Einzige Möglichkeit war, BAD-Lines abschalten (kann der DTV ja gottseidank via Pokes) und
dann, um das Flackern, daß dann entstanden ist, zu verhinden (ein parr NOPs in den Rasterzeilen-IRQ einfügen).
Das File, was ich angehängt habe, muß man allerdings schon in den Joystick flashen.
War sonst zu groß und ein Packer war mit zu lahm :->