| |
Krill
Registered: Apr 2002
Posts: 2825 |
Release id #197710 : Transwarp v0.64
General Q&A thread, also report problems and error logs here. |
|
... 162 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting WVLHow can 6 bits come out if there are only 20 different values in that table? Do not confuse the heat map with the actual decoding table, which i haven't posted. "The byte values here are just a bitfield to show which of the 5 GCR bytes may take on the index value."
I merely described a recipe of how to generate the mapping. As there is a lot more than one valid solution, i refrained from picking any specific decoding table to show here. |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Not a new trick, but a lesson i learned:
It's a good idea to skip any SYNC happening to roll by just when going to wait for a SYNC, like so
skipsync bit $1c00
bpl skipsync
waitsync [...]; SYNC time-out check
bit $1c00
bmi waitsyncThe reason is that custom loaders usually do quite a few things between the SYNC signal and the first data bytes rolling in. As the SYNC signal on standard-format disks is much longer (5 times) than the time between adjacent data bytes coming in from disk (about 26 to 32 cycles depending on track zone/density), this extra time is best not left unused in highly optimised loaders.
Now, when not skipping a current SYNC before waiting and "jumping" right into the middle or even the end of a SYNC, it may happen that there is, in fact, not the time the code requires before data rolls in, and faulty data is read.
This problem is mitigated to some extent by checksumming, but the checksum is rather weak. Faulty data may slip through, resulting in creative errors some time after actual loading.
Chances for this to happen are somewhat higher in an IRQ-loading setup, right after trackstep, and when the motor is spinning up when starting to load a file. |
| |
tlr
Registered: Sep 2003
Posts: 1703 |
Quoting Krill
Not a new trick, but a lesson i learned:
It's a good idea to skip any SYNC happening to roll by just when going to wait for a SYNC, like so
skipsync bit $1c00
bpl skipsync
waitsync [...]; SYNC time-out check
bit $1c00
bmi waitsyncQuote:
Good point! Haven't really thought about that, but might explain a few problems I've encountered during the years. :) |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting tlrHaven't really thought about that Me neither, until there were some weird transient errors during testing. This patch is one of the things i must backport to the IRQ loader. =) |
| |
Bitbreaker
Registered: Oct 2002
Posts: 499 |
Quoting KrillNot a new trick, but a lesson i learned:
It's a good idea to skip any SYNC happening to roll by just when going to wait for a SYNC, like so
The problems described sound very wellknown to me, and that is finally a good explanation why those effects happen. On the other hand, this might speed up spinup time and such in future. My first thoughts when reading this was measuring the time between two syncs, and one step further measuring the rpm and adapting a few things if too far out of range. |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Not a trick, but a caveat that has historically plagued a few loaders (former self of mine also guilty as charged on this one):
Both serial bus lines (DATA and CLK) cannot be expected to switch state at the same time.
Various analogue effects are involved, and even when flipping both bits with a single register write, the other side cannot be expected to see both changes at the same time.
E.g., when waiting for a state change using "wait: BIT $DDOO : b?? wait" and some state is communicated on the other line, $dd00 should be read again.wait: [...] do something while waiting
bit $dd00
bmi wait; wait for DATA to become asserted
bit $dd00
bvs error; just an example |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
From https://csdb.dk/release/?id=198558&show=review User Comment
Submitted by KAL_123 [PM] on 1 January 2021
Nice demo. I freezed it for my SD2IEC with a Retro-Replay, it worked. No need for dirty cartridge freeze tricks, really.
1. Use a cartridge (image)/KERNAL extension with proper saving of RAM below ROM (program code exceeds $A000), such as Action Replay fastload or similar
2. LOAD"*",8,1
3. Once the screen goes blank and starts flashing, press and hold the STOP key
4. After loading has finished, you will be back to BASIC prompt
5. Mount/insert a fresh disk (image)
6. SAVE"LOVECATS",8
You now have a clean standard-encoding copy. Enjoy with SD2IEC et al.! \=D/ |
| |
soci
Registered: Sep 2003
Posts: 473 |
I couldn't just quickly load that release over PCLink to watch it like I normally do for these sort simple stuff.
Instead it had to be written out to a disk and loaded from there. Completely defeats the purpose of it's fast loading feature if it takes more time to get to the point where it actually starts to show something.
Just for fun I tried with my 1541U2 which failed of course. Not that it matters much as I have plenty of disks and drives. Yeah, sure, everyone should probably buy the latest version right?
I have no idea what the authors were smoking. If the release is targeted to emulators or 1541U and such then for single file stuff ram injection is the way to go anyway. But for real hardware these sort of "packaging" does not add any value at all!
It's not your fault Krill of course as it's just a tool and can be used in any way. No offence, it's cool stuff.
But really, people should think before they release to make their stuff more accessible. E.g. how difficult is to upload a standalone prg version as well?! |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting sociInstead it had to be written out to a disk and loaded from there. Completely defeats the purpose of it's fast loading feature if it takes more time to get to the point where it actually starts to show something. That's true for single-consumption fire and forget stuff. For repeated playing on real original hardware, it makes sense to have it packaged like it is.
Quoting sociJust for fun I tried with my 1541U2 which failed of course. Not that it matters much as I have plenty of disks and drives. Yeah, sure, everyone should probably buy the latest version right? Pretty sure just upgrading the firmware to something recent should suffice.
Quoting sociI have no idea what the authors were smoking. If the release is targeted to emulators or 1541U and such then for single file stuff ram injection is the way to go anyway. But for real hardware these sort of "packaging" does not add any value at all! It does for multiple re-use, and on original hardware (plain vanilla stock 1541).
Quoting sociBut really, people should think before they release to make their stuff more accessible. E.g. how difficult is to upload a standalone prg version as well?! I guess they wouldn't be mad at anyone adding that to the entry. =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
Quote:Pretty sure just upgrading the firmware to something recent should suffice.
works fine with firmware 3.7 (116) here.
what a strange complaint this is :) |
| Previous - 1 | ... | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 - Next |
