Filecopy now limited to 152 blocks. ??? lol.
Hallo Besucher, der Thread wurde 33k mal aufgerufen und enthält 155 Antworten
letzter Beitrag von 64erGrufti am
JaffyDOS - A new kernal for the C64
- Tom-Cat
- Erledigt
-
-
Jaffy1.0 allowed saving under ROMs giving 200+ blx, but it caused the issue with save. Fixing it to default shrunk the save size back. Fixing it by pushing $01 , setting it and reverting it eats too much mem and would possibly cause even more surprises down the road. This is the largest challenge with modifying a kernal, you don't know what assumptions have been made from the programs calling the routines.
There is however a tiny note "Filecopier (for small files, only available in FileBrowser) "
-
There is however a tiny note "Filecopier (for small files, only available in FileBrowser) "
Good job
-
Excellent Jani ! ...if time comes i'm going to test this for sure
-
1.1 is a "quickfix" to address an issue with the saveroutine for those who need it.
I will have a second look if the filecopier can be extended back to 201 blocks. I have only 10 bytes free so we will see how/if it turns out.
-
Fixing it by pushing $01 , setting it and reverting it eats too much mem and would possibly cause even more surprises down the road.
You've kicked out the tape routines, so the tape buffer is free for trampoline code. Well, hoping that you still have enough space in your ROM.
Jens
-
-
Version 1.2 Released.
* Includes saveroutine fix from v1.1.
* Filecopy works again with files up to 201 blocks. -
Again great work Jani. Thank you very much!
-
Bug report:
Having an 8k ROM at $8000 not having a CBM80 string by using an external module, Jaffydos incorrecntly reports 38911 bytes free instead of correct 30719 bytes free.
BTW: S-Jiffydos handles that case correct and has a fast reset routine.
-
it's a bit deliberate because it ignores memcheck.
-
I see. But checking a singel address in the range $8000-$a000 would make the distinction possible. And it would not need more time (microseconds do not count for practical purposes).
-
Is this so important? Noone EVER will miss this, also I don't think there is a single byte free anywhere in the rom now
-
Is this so important?
Yes, it is. There are carts that do not use CBM80 auto-start, but start with a SYS by the user. These require the Basic pointers to be in the correct location. Further, there may be more modern carts with flash that use a 30719 bytes-free mem config in order to show "I'm here, but I don't do anything right now" for a de-brick function (I don't fully remember, but I think MMC Replay does it this way - Retro Replay surely does not).
Someone with more knowledge may correct me here, but I think that LOAD and SAVE use the last bytes of Basic mem to store the file name. This may fail if the $AFF0 area is not available as RAM, but listed as available.
So in essence, you're introducing an incompatibility, which is a bad thing in C64-land. Try optimizing a few more routines; there's the screen editor and lots of text in the Kernal. So instead of "Basic bytes free", a simple "bytes free" message will do. Or look at $ECE7, there's the LOAD and RUN commands fully written out - you can use abbreviations there. Also, RS232 routines appear awfully long to me. There's surely lots of potential for optimizing.
Jens
-
It kind of boils down to free memory.. there is literally no free memory left (10 bytes or so, with reservation for F-key mods). I had a check for $8000 but IIRC the md64/71/81 ate the last of the memory at that point.. so, I had to choose to have a mem(cart)check or discard md64/71/81. Something has to go, to be able to add more functions.. In this case the MD64/71/81 seemed more useful. (The RS232 routines are removed, so nothing to optimize there.)
I think both Tom-Cat and Wiesel have valid points here.
On the second hand, I don't think it is a real life issue, or a very small one... what's the likelihood trying to debrick MMC while running Jaffydos ? ...but again on the other hand, it for sure could cause problems like Wiesel says. Totally valid.
For (in)compatibility issues, i think the bigger problem would be Tape and RS232, which are both removed. In that case you should have a switchable kernal (like I assume many of them users have).
But in the bigger picture, I don't think Jaffydos introduced an incompatibility, I think it introduced a compatibility with SD2IEC.
thanks for the feedback, you got me thinking, so maybe I should revisit the idea of check at $8000
-
It kind of boils down to free memory..
...which is why so many external carts used banking in order to have some more free space. With users being very creative in combining whatever hardware and software they own, it's always a challenge to keep the balance between sacrificing features and adding new ones.
With the C64 community being very active these days, we may be able to establish a standard for extended Kernal ROMs. We have reverse-engineered an interesting cartridge by Dela a few years back here on F64; it used extra bits in a separate Eprom to introduce automatic banking. So if a routine runs "linear" through a certain address, it will be re-directed to extra space, which will overlay the actual Kernal. Should anything jump directly to that location, it will reach the actual Kernal ROM. Think of it as a stairway to another bank that is only positioned at points that are not used as direct entry points. Once you're in the overlay-bank, you have all the space you can think of, as you can jump around in 8k of extra space. And the idea isn't even limited to 8k; in theory, you can give it lots of extra banks, as you have at least seven bits for banking.
For a return point, the same technique can be used - assuming that the normal Kernal is bank#0 and the "stairway field" is switched along with the Kernal bank, possibilities are extremely wide.
Jens
-
Having a kernal with banking would be really neat. (I have made a (unpublished) DTV kernal which has a toolmenu with filecopier,diskcopy,monitor and fastload. It banks in memory above 64K to fetch/exec code and returns to kernal when done.)
-
Hallo,
nur eine kurze Frage: Daß bei JaffyDOS steht "RS232 removed" bedeutet, daß z.B. ein Userport-Wifi-Modem dann nicht mehr funktioniert, richtig?
Danke!
Viele Grüße
Anna -
Daß bei JaffyDOS steht "RS232 removed" bedeutet, daß z.B. ein Userport-Wifi-Modem dann nicht mehr funktioniert, richtig?
Ja, ist leider so...
-
Ja, ist leider so...
Okay, dankeschön!
Dann lohnt sich das für mich doch nicht wirklich.Viele Grüße
Anna