Important news and I need some help.

[+acadiel]

It's about time to kill that silly copy protection. (Even if it's simply because it's there.)

I actually have the source code coming for Explorer and DiskAssembler. At a very basic level, he tells the write head to go to a certain track and then write a 1K sector. Same thing with a read. Direct access based on the chip (WD1771 or WD1773) and floppy card type. There’s some info in that long sector that’s part of encrypting the executable.

 

I’m going to KyroFlux the disks just to preserve them as distributed. I have executables of them with the protection removed that someone on here gave me, but I can also just recompile DiskAssembler and Explorer from source now without the protection once I get the source. Would love to compare it to the versions that had the protection removed. Advanced Diags, though, I won’t have the source for.

[+mizapf]

Most copy protections have some kind of JEQ/JNE operation that waits to be replaced by a NOP.

[+9640News]

The module 4A/Flyer had some similar copy protection. As the module was in ROM in the >6000 to >7FFF memory space, it would attempt to modify an address. If it was ROM, it would not change. If it was being run in RAM without the memory write protection switch turned off on the GramKracker, it would would write to the instruction. Then, when code was run in that area, it would stay in an endless loop and hang.

 

Beery

[+acadiel]

The module 4A/Flyer had some similar copy protection. As the module was in ROM in the >6000 to >7FFF memory space, it would attempt to modify an address. If it was ROM, it would not change. If it was being run in RAM without the memory write protection switch turned off on the GramKracker, it would would write to the instruction. Then, when code was run in that area, it would stay in an endless loop and hang.

 

Beery

Tursi and I found quite a few of those when making the 8K program 512K multicart and patched them. We didn’t go through the 16K ones. However, I think most of the problematic ones were the Databiotics ones.

[+9640News]

I suppose what I meant is, * is there enough software out there that can only reside on a DD diskette to warrant the additional work to implement the double density emulation.

 

But if the additional effort is nominal, then it doesnt really matter.

 

I would definitely say yes. It may not be so much as software, but perhaps source files. I do a fair amount of copy files to floppy to be archived, archive them, then upload them. DS/SD just is not enough space. Even DS/DD is pushing it at times.

 

Beery

[+mizapf]

The module 4A/Flyer had some similar copy protection. As the module was in ROM in the >6000 to >7FFF memory space, it would attempt to modify an address. If it was ROM, it would not change. If it was being run in RAM without the memory write protection switch turned off on the GramKracker, it would would write to the instruction. Then, when code was run in that area, it would stay in an endless loop and hang.

 

These are still simple ways of copy protection. If you have the source code and find this test routine, it suffices to modify a single word (e.g. the address where it writes to). Also, in those schemes that I mentioned, the boolean check must be removed, and things should work well.

 

I myself used an integrity check in my Fractals program (which I am a bit embarrassed about now) which did the following:

 

- Calculate a checksum over the used memory (adding all bytes, maybe doing some other voodoo)

- Add a constant a0 to that value to calculate an address a

- Add another constant v0 to that value to create another value v

- Add (or xor or whatever) that value v to the existing value at address a

 

If something has been changed, you get another value for a and for v, which probably breaks some other instruction, but at least does not modify the instruction at address a.

 

So I assembled the program, then I had another tool that runs the checksum routine and calculated the values a0 and v0, which I wrote into the program code. The target address was set to be in the main menu loop, so it had a broken instruction that immediately locked up the program.

 

This is slightly more complicated to remove, since you must find out which instruction is bad, requiring you to disassemble the program and find out where I put the bad instruction. But not impossible. (Note that with today's tools like emulators with debuggers, you can possibly find out rather quickly, just need to compare the memory dump of the running program with the program code.)

 

---

 

I don't know detail of the copy protection of MG. What is indeed possible:

 

- Use a non-standard track layout. You may then try to read the whole track and check the sector sequence. COPY-C should handle that.

- Use a non-standard sector size. You can indeed change sector sizes whereever you want, since the sector size is defined in the sector header of each sector. Not sure whether COPY-C can cope with that.

- Things are becoming rather ugly when the program loads data from that sector that is supposed to be executed. If you cannot copy that sector, or if you kill the protection check routine, this code will be missing.

[+Schmitzi]

And I have a DSDD 80 track, so this is very interesting too

And why not, if he is going to do that at all.

 

And please let him know that we are talking about V9T9-DSK, and not the PC99-DSK format (!)

As PC99 is more described on NinerPedia than V9T9, don´t let him go the wrong route

just because of NOT telling it to him explicit

[RickyDean]

Yes, DSDD is a must and even DSHD for the Geneve too.

[+mizapf]

OK then ... https://www.ninerpedia.org/wiki/Sector_Dump_Format

 

Looks better, I suppose.

[Sinphaltimus]

And I have a DSDD 80 track, so this is very interesting too

And why not, if he is going to do that at all.

 

And please let him know that we are talking about V9T9-DSK, and not the PC99-DSK format (!)

As PC99 is more described on NinerPedia than V9T9, don´t let him go the wrong route

just because of NOT telling it to him explicit

Done.

 

EDIT: Response from Kaffer - "Yes no problem, it is a fairly straightforward sector-dump format. It's just the track format is FM (for the single density images at least) and I need to add the read/write support for that. What I will do is implement preliminary support and then send pre-release firmwares for testing."

Edited March 15, 2018 by Sinphaltimus

[Opry99er]

Excellent!!

[Jeff_HxC2001]

RAW/Sector dump FM (and MFM too) dsk images are of course supported by the HxC firmware for Gotek (about since a year.).

Edited March 31, 2018 by Jeff_HxC2001

[Sinphaltimus]

RAW/Sector dump FM (and MFM too) dsk images are of course supported by the HxC firmware for Gotek (about since a year.).

 

I'm not really up on floppy tech or anything so I'm not sure what RAW.Sector dump is. I did try some TI specific dsk images with your last release and couldn't get them seen, which is also why I contacted you about the TI's specific DSK image format. Hopeful to see that in HxC as that's the current firmware on my TI's GoTek. I was under the impression we might see that sometime this year as per our last private msg exchange. If I am completely not understanding then I would certainly like to. Currently those of us with GoTeks and HxC are using HFE as the format (having to create and populate HFE images on a PC from scratch or from an existing dsk file).

 

I think, as seen here in this topic, there is a need/desire to have v9t9 dsk support for GoTek and for Lathorak drives. Much the same way adf is supported on Amigas. Compatible with existing images for real iron (via floppy emulation) and in emulators such as classic99 and JS99er, MAME and more.

 

Thanks for the info Jeff, please do explain further in case I'm misunderstanding something. I think you've piqued the interest of everyone currently using HxC firmware.

[Jeff_HxC2001]

I think you've piqued the interest of everyone currently using HxC firmware.

 

Not so sure, but anyway, here is a new firmware for the TI99/4A with direct TI V9T9/DSK images support:

 

http://hxc2001.com/download/floppy_drive_emulator/HXCFEUSB_HFE_beta_firmware.zip

 

http://hxc2001.com/download/floppy_drive_emulator/USB_HFE_hxc_floppy_emulator_firmware_release_notes.txt

 

 

1 April 2018: Firmware STM32 USB HxCFloppyEmulator v3.1.22.1a

 

- TI99/4A : Direct support of *.DSK/*.PC99/*.V9T9 sectors dump images

SD/DD/HD density support (Read & Write).

 

- New embedded menu entry : You can now force the user interface mode

(Normal/Indexed or selector mode selection).

 

EDIT : Since the TI formats can clash with other machines formats, i recommend you to select the "TI99/4A" system family in the embedded menu to have a better image format selection, especially with images with the "dsk" extension.

Edited April 1, 2018 by Jeff_HxC2001

[Sinphaltimus]

Thanks Jeff, I'll check it out after the holiday activities settle down.

[Sinphaltimus]

OK, had about 15 minutes to spare and I spent most of that time using the built is configuration utility on my LCD display for the first time ever.
I changed mode to NORMAL and set family to TI-99/4a and I'm not sure but I think I set that other drive setting to SHUGART since the default was HFE files.
I'd have to review my settings for sure but after updating to that firmware in your link, reconfiguring my GoTek and copying some dsk files over...

It works to the point that I can select an HFE image or a DSK image by file name and load it. I was also able to catalog a disk in this case I used MGAMES-III.dsk and it worked.

I haven't run any programs from DSK or tried anything else, like formatting or copying files (using DM2K or anything else.

Just catalogued the DSK file in basic that's it.

 

I hope to get back to it after work today and see how it behaves initializing dsk files, copying disks and copying files of various capacities and formats.

I invite anyone else to do the same.

[Jeff_HxC2001]

OK, had about 15 minutes to spare and I spent most of that time using the built is configuration utility on my LCD display for the first time ever.

I changed mode to NORMAL and set family to TI-99/4a and I'm not sure but I think I set that other drive setting to SHUGART since the default was HFE files.

I'd have to review my settings for sure but after updating to that firmware in your link, reconfiguring my GoTek and copying some dsk files over...

 

No need to set the interface mode. when you select the system, the right interface mode is used too.

 

It works to the point that I can select an HFE image or a DSK image by file name and load it. I was also able to catalog a disk in this case I used MGAMES-III.dsk and it worked.

 

I haven't run any programs from DSK or tried anything else, like formatting or copying files (using DM2K or anything else.

 

Just catalogued the DSK file in basic that's it.

 

I hope to get back to it after work today and see how it behaves initializing dsk files, copying disks and copying files of various capacities and formats.

 

I invite anyone else to do the same.

 

Try the most important thing first : normal read & write to the dsk/v9t9.

 

BTW format an dsk/raw file seems odd to me since the format used is related to the file image size. Unless you are 100% sure that image format match with the disk layout used during the disk format, this may fail.

HFE images are better for this since this file image store the whole track with all details sent by the machine during format process.

[Sinphaltimus]

I was able to do some more testing and here are my results:

Using ti99DIR I created 4 dsk files as follows:
SSSD360.dsk
DSSD720.dsk

DSDD1140.dsk
CF7A1600.dsk

each of the above with 40 tracks selected at creation time. CF7A is non standard and only used for nanPEB, i did nto think this would work but I tried anyway.

The results from those tests are:

SSSD360.dsk - initialized fine as SSSD 40- track, was able to copy catalog program to it, load catalog program from it and run catalog program.
DSSD720.dsk - initialized fine as DSSD 40- track, was able to copy catalog program to it, load catalog program from it and run catalog program.

DSDD1140.dsk - Not able to initialize Disk Error 17 in DiskManager 2 program - 1-Device write protected(attempting to write to a protected file): : 7-File error(the indicated file does not exist or the file type;program file or data file does not match the access mode.)
CF7A1600.dsk - Not see by GoTek - No Worries, not important.

Using TIImager I wa able to create uninitialized dsk images at 80 tracks each, they are:
SSSD80.dsk

DSSD80.dsk

DSDD80.dsk

 

The results were:

SSSD80.dsk - GoTek reads disk as 40 track not 80 however; - initialized fine as SSSD 80- track, was able to copy catalog program to it, load catalog program from it and run catalog program.

DSSD80.dsk - GoTek reads disk as 40 track not 80 however; Not able to initialize disk error 31 in DiskManager 2 program :: 3-Illegal operation(Input/output command not valid) : : 1-Device write protected(attempting to write to a protected file)

DSDD80.dsk - Not able to initialize Disk Error 17 in DiskManager 2 program :: 1-Device write protected(attempting to write to a protected file) : : 7-File error(the indicated file does not exist or the file type;program file or data file does not match the access mode.)

I can confirm my HFE files work and they are setup as DSSD 80 track HFE files.

I have not been able to get any programs to load off of a handful of dsk files we have in archives: I could be doing something wrong here as I have never loaded these particular programs before. I will have more time to do more extensive testing this weekend. If I can squeeze in some mroe time during the week I will.

Attached are the dsk files I created and tested with.

Custom.zip

And these are the existing programs one I could not load anything from - perhaps another TI-99er could tell me why. I may not have chosen optimal dsk files to test with using BASIC, Extended BASIC and I even tried EA5 load/run.

I.zip

 

[Jeff_HxC2001]

DSDD1140.dsk - Not able to initialize Disk Error 17 in DiskManager 2 program - 1-Device write protected(attempting to write to a protected file): : 7-File error(the indicated file does not exist or the file type;program file or data file does not match the access mode.)

File size matching with the the classic 40*18*2*256 DD/MFM format. This is not the right format ?

 

What mean "1140" in the file name ?

 

CF7A1600.dsk - Not see by GoTek - No Worries, not important.

Anyway will add the descriptor for this one.

 

The results were:

SSSD80.dsk - GoTek reads disk as 40 track not 80 however; - initialized fine as SSSD 80- track, was able to copy catalog program to it, load catalog program from it and run catalog program.

DSSD80.dsk - GoTek reads disk as 40 track not 80 however; Not able to initialize disk error 31 in DiskManager 2 program :: 3-Illegal operation(Input/output command not valid) : : 1-Device write protected(attempting to write to a protected file)

File sizes clashing with double sided images sizes... will add something to try to detect the number of sides for these one, but i don't plan to support the number of side change (real time change between the 80*1 and 40*2 formats)

 

I have not been able to get any programs to load off of a handful of dsk files we have in archives: I could be doing something wrong here as I have never loaded these particular programs before.

...

...

And these are the existing programs one I could not load anything from - perhaps another TI-99er could tell me why. I may not have chosen optimal dsk files to test with using BASIC, Extended BASIC and I even tried EA5 load/run.

No particular reason to have issues with these DSKs, so i want understand what is the problem here... Which error did you get exactly ?

Have you tried to convert them to HFE and run them ?

Have you at least successfully run some others programs from others DSK ? (if yes, with the same file image size or different ?)

Edited April 3, 2018 by Jeff_HxC2001

[Sinphaltimus]

File size matching with the the classic 40*18*2*256 DD/MFM format. This is not the right format ?

 

What mean "1140" in the file name ?

 

 

Anyway will add the descriptor for this one.

 

 

File sizes clashing with double sided images sizes... will add something to try to detect the number of sides for these one, but i don't plan to support the number of side change (real time change between the 80*1 and 40*2 formats)

 

 

No particular reason to have issues with these DSKs, so i want understand what is the problem here... Which error did you get exactly ?

Have you tried to convert them to HFE and run them ?

Have you at least successfully run some others programs from others DSK ? (if yes, with the same file image size or different ?)

 

File size matching with the the classic 40*18*2*256 DD/MFM format. This is not the right format ?

 

I don't know, i would like to get some help from folks much more knowledgeable in TI floppy formats than i to help with some responses.

 

What mean "1140" in the file name ?

 

Anything with an "80" in the filename means it's an 80 track version. Anything with 360, 720, 1140 or 1600 in the filename means it is a 40 track image and that number is the total sectors. So DSDD1140 = Double Sided Double Density 40 track with 1440 total sectors for example.

 

No particular reason to have issues with these DSKs, so i want understand what is the problem here... Which error did you get exactly ?

 

I have to confirm these disks are good ones to try and I am not loading them correctly. I am getting "check program in memory" errors which can mean that I am loading them incorrectly or that they need a specific cartridge inserted first. I will go through my dsk collection and find programs and games I know to work in emulation and then use those instead.

 

Have you tried to convert them to HFE and run them ?

 

No, not yet.

Have you at least successfully run some others programs from others DSK ? (if yes, with the same file image size or different ?

 

No, I haven't found a dsk file I can successfully load from yet but I only tested the few I attached. With limited time last night I just picked a few without consideration for their requirements. I will however test dsk images I that are known working in basic or extended basic. Hopefully before the weekend.

[RickyDean]

I do not know if this is a problem or not, but TI sort of reverses the industry standard of reading from the second side, if I remember correctly.

[+mizapf]

I do not know if this is a problem or not, but TI sort of reverses the industry standard of reading from the second side, if I remember correctly.

 

Yes, what I already said earlier. On a 1440 sectors disk, sector 0 is on side 0 (bottom), outermost cylinder, sector 719 is on side 0 (bottom), innermost cylinder, sector 720 is on side 1, innermost cylinder, and sector 1439 is on side 1, outermost.

[Jeff_HxC2001]

I do not know if this is a problem or not, but TI sort of reverses the industry standard of reading from the second side, if I remember correctly.

Sure. This is already supported by the HxC Firmware.

[Jeff_HxC2001]

No particular reason to have issues with these DSKs, so i want understand what is the problem here... Which error did you get exactly ?

 

I have to confirm these disks are good ones to try and I am not loading them correctly. I am getting "check program in memory" errors which can mean that I am loading them incorrectly or that they need a specific cartridge inserted first. I will go through my dsk collection and find programs and games I know to work in emulation and then use those instead.

ok let me know for these dsk.

 

i already have a fix for the clash format detection, will test it on the real hardware in some hours and release it.

[RickyDean]

 

Yes, what I already said earlier. On a 1440 sectors disk, sector 0 is on side 0 (bottom), outermost cylinder, sector 719 is on side 0 (bottom), innermost cylinder, sector 720 is on side 1, innermost cylinder, and sector 1439 is on side 1, outermost.

Sorry must have missed that, I don't have internet at the house, so I have to get my 'fix' while at work, and sometimes in the saving of the web sites to read through later, I miss things.

Edited April 3, 2018 by RickyDean