Author Topic: CubeMDOS / FAT16+FAT32-OS - for XMASS, Symbiface_2+3,HXC/FlashFloppy  (Read 36683 times)

0 Members and 1 Guest are viewing this topic.

Offline m_dr_m

  • CPC6128
  • ****
  • Posts: 261
  • Country: se
  • http://orgams.wikidot.com/
    • OrgaMS!
  • Liked: 172
  • Likes Given: 187

Offline m_dr_m

  • CPC6128
  • ****
  • Posts: 261
  • Country: se
  • http://orgams.wikidot.com/
    • OrgaMS!
  • Liked: 172
  • Likes Given: 187
Request #1c: |getpath rsx should return "A:" in |a mode, and HXC path in |Ha / |Hb mode.
Rationale:
* More consistent with other DOS
* |A / |D doesn't set current drive (&a700 by default) -> It makes hard to know programmatically which drive is active!


Thank you!




Offline SOS

  • Supporter
  • 464 Plus
  • *
  • Posts: 388
  • Country: de
  • Identity lost
    • index.php?action=treasury
  • Liked: 255
  • Likes Given: 276
Request #1c: |getpath rsx should return "A:" in |a mode, and HXC path in |Ha / |Hb mode.
Hmm, this is more complicated as expected.
YANCC uses this function, so it need to be changed.
The function is also be programmed in M4Dos, so it need also be changed.


* More consistent with other DOS
* |A / |D doesn't set current drive (&a700 by default) -> It makes hard to know programmatically which drive is active!
&a700? you must get the correct address from &be7d.
CubeMDOS is here 100% like amsdos

Btw. the loading of large files >64kb seems now to be working (save is open).
But i have no success in testing this with orgams and - what makes me very confused - big problems with only orgams+amsdos (no other ROMs / Mass Storages). Can you please send me a testing file with PM , which i can load & (later) save with orgams?

Offline m_dr_m

  • CPC6128
  • ****
  • Posts: 261
  • Country: se
  • http://orgams.wikidot.com/
    • OrgaMS!
  • Liked: 172
  • Likes Given: 187
Bug #80 AMSDOS vs CubeMDOS: Different behaviour for DISC IN CHAR past hard end of file

First I'll start with *common* behaviours: when &1A (ASCII for End Of FILE) is met, flags are NC, NZ.
But for binary files, &1A is a byte like another.
So we dismiss the flags and continue reading, the behaviour is still the same (next char properly read, Carry if not another &1A).


Now, past the "real" end of file, if we continue reading:
* On AMSDOS: We get Carry with garbage chars, until we reach end of AMSDOS "record" (&80 long chunk). Note: that's because AMSDOS cannot know the real end of file, since the precise length is unknown, only the number of records.
* On CubeMDOS: We get &1A, NC, NZ forever.


Implication: if we use a routine that read until flags NC,Z:
- On AMSDOS, we might read a bit too much (post EOF garbage). That's not an issue in most cases.
- On CubeMDOS: infinite loop.
This provoked bug #11c on Orgams :)


Now the caller can use a workaround:
- For pure ascii text, stop at &1a.
- For binary text, the caller needs to know the real length in some way, or use an unambiguous sentinelle.
Yet it would be nice to be as compatible as possible.


Reference: see joined little source used for analysis.