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

0 Members and 1 Guest are viewing this topic.

Offline m_dr_m

  • 464 Plus
  • *****
  • Posts: 327
  • Country: gb
  • http://orgams.wikidot.com/
    • OrgaMS!
    • Awards
like
0
No reactions

Offline m_dr_m

  • 464 Plus
  • *****
  • Posts: 327
  • Country: gb
  • http://orgams.wikidot.com/
    • OrgaMS!
    • Awards
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!



like
0
No reactions

Offline SOS

  • Supporter
  • 464 Plus
  • *
  • Posts: 388
  • Country: de
  • Identity lost
    • index.php?action=treasury
    • Awards
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?
like
0
No reactions

Offline m_dr_m

  • 464 Plus
  • *****
  • Posts: 327
  • Country: gb
  • http://orgams.wikidot.com/
    • OrgaMS!
    • Awards
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.
like
0
No reactions

Offline CraigsBar

  • Supporter
  • 6128 Plus
  • *
  • Posts: 3.381
  • Country: ie
  • The party ain't over yet
    • index.php?action=treasury
    • Awards
Yes |DRIVE is caught by CubeMDOS, but when execute, i'm doing a decision "ParaDOS found?", so if yes, I execute the ParaDOS-RSX.
Works here   
Could you reproduce that in WinApe?
Same effect with Parados 1.2?
You can attach the big-floppy-drives? (so Parados is loaded correctly)
Please, could you send me the "?peek(&b0c7)"  and b0c8 & b0c9 values

SOrry to dig up such an old topic. But i have just got around to installing this all on my XMASS on my 2nd 6128+ that has no mods. I will however be using a Parados 1.2+ cartridge to get rid of the boot menu!

Here's the problem. As detailed by the original poster, I cannot access the DRIVE for Parados, I guess because it is the 1.2+ version. Anyway the requested PEEK'ed values are

&b0c7 = 5
&b0c8 = 6
&b0c9 = 36

like
0
No reactions
IRC:  #Retro4All on Freenode