Jump to content
janzh

Fast Assembler

Recommended Posts

I was searching for an assembler to develop on original hardware. I found Fast Assembler for Sparta DOS X by Marek Goderski from MMMG Soft (Free MG) from 1995 (!!!).

 

I was impressed because the assembler has the following features:

  • Support of SpartaDOS X and Atari DOS object files
  • Support of relocatable SpartaDOS X blocks
  • Support of SpartaDOS X symbols
  • The maximum file length of the source code and object data only depends on the file system, as it is a real file to file assembler

 

I ask Marek for sources but they are not available anymore but he gave the Fast Assembler to the Public Domain. So I started to disassemble it, refactored the source, wrote some examples, and add documentation with tutorial. Now I think it is a nice development package especially because JFC allowed me to add XEDIT.

https://github.com/HolgerJanz/FastAssembler

 

Fast Assembler is fully compatible with Quick Assembler, but is not compatible with MAC/65 or Atari Assembler Editor. The Fast Assembler syntax is supported by MADS the 6502 cross  assembler (Fast Assembler can assembled using Fast Assembler itself or MADS). MADS is available for macOS, Linux and Windows (https://github.com/tebe6502/Mad-Assembler).

 

So I hope other people will also have fun with this package.

 

To try this package be myself I have developed a game for the ABBUC Software Contest 2021:

https://github.com/HolgerJanz/VARIUS

 

Everything was developed using an Atari 800XL with Ultimate 1MB upgrade and Side3. The emulator Atari800MacX was only used to test the package on different configurations.

 

Regards

Holger

 

BTW - Next step is to port it to SpartaDOS 3 compatible so one can cross develop from SpartaDOS 3 to X and vice versa.

 

  • Like 14
  • Thanks 3

Share this post


Link to post
Share on other sites

Might want to offer the .ATR in a couple more formats... SSSD SSDD, the current DSDD image is very nice. Many SpartaDOS 3.xx users have USD1050's so SSDD is a natural fit.

Edited by _The Doctor__

Share this post


Link to post
Share on other sites
1 hour ago, _The Doctor__ said:

Might want to offer the .ATR in a couple more formats... SSSD SSDD, the current DSDD image is very nice. Many SpartaDOS 3.xx users have USD1050's so SSDD is a natural fit.

 

I added different packages:

FA.ATR - SSSD - Executable, Man Page, and Examples

FA_with_Docs.ATR - SSDD - plus Documentation

FA_with_Docs_and_Sources.ATR - DSDD - complete

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
19 hours ago, kenames99 said:

excellent! if you need or want any help with the SpartaDOS 3 port just let me know.

 

Ken

 

Hi Kenn,

 

Help would be great. The sources of FA are already prepared. FA.ASM contains the SpartaDOS X dependent part. The idea is to create a new file FA3.COM (and maybe rename FA.ASM to FAX.ASM).  Here the Reloc block will be changed to DOS block and for all SpartaDOS X symbol new subroutines must be implemented, e.g. FOPEN, PRINTF etc. Just drop me a PM for further details and discussion. My favorite SpartaDOS 3 compatible DOS is BW-DOS (it does not use RAM under OS and still has a MEMLO around $2000). I started to disassemble it and tweak it, too.

https://github.com/HolgerJanz/BW-DOS 

 

Holger

Share this post


Link to post
Share on other sites

oh man, that's cool. bw-dos src. I offered help because I am a core maintainer of realdos which is sprtados 3.2 compatible. I am currently really busy, hope to be unshackeled soon but going to be about 2 weeks yet. I will download your code and start getting up to speed on it.

 

Ken

 

Share this post


Link to post
Share on other sites
On 12/1/2021 at 10:22 AM, janzh said:

Hi Kenn,

 

Help would be great. The sources of FA are already prepared. FA.ASM contains the SpartaDOS X dependent part. The idea is to create a new file FA3.COM (and maybe rename FA.ASM to FAX.ASM).  Here the Reloc block will be changed to DOS block and for all SpartaDOS X symbol new subroutines must be implemented, e.g. FOPEN, PRINTF etc. Just drop me a PM for further details and discussion. My favorite SpartaDOS 3 compatible DOS is BW-DOS (it does not use RAM under OS and still has a MEMLO around $2000). I started to disassemble it and tweak it, too.

https://github.com/HolgerJanz/BW-DOS 

 

Holger

Post the truth.  Memlow is better on sdx but f**King memtop sucks because it is a cart.    Using it on an unmodified Atari with a disk drive is painful. Now there have been wonderful Hardware upgrades mostly out of Poland but not all all new hardware has not been exclusive to Poland. My hat comes off to all the wonderful  I had from ICD the third SDX cart then Keith Ledbetter, Chris King and myself started on the Express Cart.  When Ken Ames contacted about making some changes to my Version of SpartaDos 3.2c to Work with BBSExpress Professional and the NEW CSS Multiplexer. Do not think that RealDos was just a rebrand it is not. I had real source from MG.  I was the only person on earth that was allowed to view ICD source.  The SIOV routines are very different. Ans since we are talking about SDX  which I am very happy to have provided the equipment and tech help on.Fix it to where any SDX loaded CART will work with all hardware. do not hold your compiler to tight because I can turn any atari code back to source and yes I know how to do relocatable code. MY health has bounced back and as soon as I can get my eyes operated on. Here one question for you? Have you used the new wedge.com the one that works with all SpartaDos Disk version after 3.2d and all RealDos Versions.  AMES talked me into that. At the moment I am not programming because of my eye's. Between Ken and I we have 78 years of knowledge and I have two of every bit of Atari hardware made.

     Because of my wife Passing away 12/21/2019 and vision problems I have turned 100% of my documented source to Ken Ames. I did this for two reasons. My health has not been the best and I did not want that source to be tossed away.  I also published all the source to the Realdos Toolkit to everyone in the world. JUst so I do not get Hate mail Thank you all you new programmers and hardware developers.

 

Seprate note. Before any non professional solderers take your non-socketted Atari to put in an upgrade please Veiw the U-Tub clips FlashJazzCat has made. Thanks Jon

 

Dr. Stephen J. Carden PhD

  • Like 2

Share this post


Link to post
Share on other sites
8 minutes ago, Stephen J Carden said:

Memlow is better on sdx but f**King memtop sucks because it is a cart. 

You use the 'X' command to run software which needs MEMTOP at the usual location. This turns the cart off. ;)

8 minutes ago, Stephen J Carden said:

Using it on an unmodified Atari with a disk drive is painful.

I used the original SDX cart on a 64K Atari for quite some time (in the 90s) with nothing but an XF551 for storage. Admittedly, the experience was even better with 128K, but in neither case was it 'painful'.

8 minutes ago, Stephen J Carden said:

Veiw the U-Tub clips FlashJazzCat has made. Thanks Jon

Pleasure!

Edited by flashjazzcat
  • Like 1

Share this post


Link to post
Share on other sites
17 hours ago, flashjazzcat said:

You use the 'X' command to run software which needs MEMTOP at the usual location. This turns the cart off. ;)

I used the original SDX cart on a 64K Atari for quite some time (in the 90s) with nothing but an XF551 for storage. Admittedly, the experience was even better with 128K, but in neither case was it 'painful'.

Pleasure!

Thanks Jon for pointing out to the world of SDX users about the X.com function within SDX. I am aware of it. Like with movies, Books, Who is running a company or country people view and feel different about everything. Do NOT THINK I do not use, test, and find The Atari Needs a cart based DOS like SDX. Each Dos that has ever been written for the Atari has been done for one or more reasons. There are program that have been written for one or more reasons that need a dos of one kind or another. Excluding the GAME Carts Like Packman or Defender and all the rest of them. If anyone has ever tried to come up with a list of all the cart out there I would love to get them or an image of there rom. Tom Hunt wrote a program called Snapshot that would copy from $0000 to $FFFF and current state of Stack which with a touch of a button go between two or more program. A program very much ahead of its time. However the X.com in SDX does turn $8000 to $ BFFF from the bank switch cart off so a com file can use or run in that space but the program now running can no longer use a JSR into a dos subroutine or be certain that dos info is there. One of the Functions That only SDX has very right is a way to relocate dos JSR from under the OS or the subroutines starting $C000. ICD's MG toolkit very much used the Print inline String and others. That is how the Disk Based SpartaDos was penned. DID ICD Get it right that just depends on who you are talking with. One of the reasons there are so many different reasons different DOS's I guess but I am sure there are different debates on the topics. Do not get me wrong I like SDX, I like SpartaDos from way back in the version 2.3 days. For the most part I will use whatever works. If there is nothing out there to get the job done. I will write what I need. Any Atari users out there Please learn how to program. This way you are not just a user but an author! Working with the Atari for so many years I am still humbled by some of the new programs written since 2000. Yes I Published my entire RealDos Toolkit. I did this to help the new programmers could see how the old Farts like myself did things. Now I did not Publish the RealDos .dos file because novices have no need to program there. I have seen a mistake in .dos file wipe out an entire hard drive. Like SDX I have been USING my own Custom Cross-Assembler Since 1985. First on my Mega 4 ST then later on my PC. 

    When I was codding for BBS Express Professional Bob Puff came out with SuperArc and Unarc I called Puff on the phone and let him know that I would very much like to include ARC and Unarc inside BBS Express Pro. He Told me Carden if you want it take it apart. He would not turn the source over for that project. My response to Bob was are you really sure you want to do this in that manor. His response was yes. That was on a Friday. 48 hours later I uploaded my source for his ARC and UNARC to his BBS. 48 hours later BBS Express Professional now had ARC and UnARC programs linked into the message base networking. Compressing the message bases by 90% and saving those Sysops Thousands of dollars. That update made me a lot of money. But you already know this story! Is this not how the Updated SDX came about.  That now lives in all the cool new hardware like U1meg, Side, Side 2, Side 3, IDEa, IDE Plus 2.0 just comes quick to my mind. Which I do not have a problem with how it came about. I am very happy for the work that was put into it and the hardware it now lives. Here is the point I am trying to make! Do not think a compiled code can not be turned back into source and have it come back at you.

 

Everyone please note I have the greatest respect for all the new hardware and software. The list of programmers and hardware designers for the Atari is better than it has ever been during the 1983---1999. This is NOT something I would Do myself. You are a big part of that FlashJazzCat but one of your programs that flashes hardware could have one JSR change to a chip rendering hardware useless. You know Pull the hardware and reprogram from scratch. So the one change that is needed is a hardware lock switch to prevent this. Some of the sd cards have hardware locks as well as the all CSS versions of the BlackBox. This is a design change I would like to see in the hardware that has ramdisk is a battery backup. My Ramdisk.Com already supports this.  I hope this never happens but I am sure there is some teenager wanting to mess up dad's vintage hardware. This very reason is why so much of our Windows Software Computer spend so many processor ticks on Anti Virus Utility's. This is also why my updated toolkit has a space that can hold a crc value. This can do two things Stop a mod to a program and tell the user there is a problem.  This is not anything I came up with but the guy who did the very first sio2pc. I sorry I can not remember his name. I started to use this in the RealDos toolkit. The include is called Header.s, Set-crc.s, Version.s, and checkcrc.s. Once I get my fixed I have plans to create an editor that can change how each of the RealDos toolkit Utilitys run. One of the things I really love about the Atari 8-bit is how so much can be done in 64k. I really like being an end user who writes code every now and then. The mod's I have suggested are something I would like to see. All of you doing this wonderful work keep it up. But the changes I have pointed out are needed. I will just kick back, get my eyes fixed so I can join with the other users and enjoy all the new stuff. I do enjoy what you do Jon and so do many others. The U-Tub Videos have been needed and they are great!

 

Take care all. God Bless the Atari ship we are on and enjoy!

Steve

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, Stephen J Carden said:

This is not anything I came up with but the guy who did the very first sio2pc. I sorry I can not remember his name.

Nick Kennedy

 

2 hours ago, Stephen J Carden said:

Do not think a compiled code can not be turned back into source and have it come back at you.

I know what you mean, I wrote a disk duplicator that used a 130XE total memory to save

the amount of disk swaps required when duplicating a floppy, it did SSSD,SSED & SSDD disks.

 

I saw a program many years later and although it looked different than the one I wrote, when

I disassembled the code, I recognised many areas that matched my code (too many to be a coincidence) 

Share this post


Link to post
Share on other sites
2 hours ago, Stephen J Carden said:

Thanks Jon for pointing out to the world of SDX users about the X.com function within SDX. I am aware of it. Like with movies, Books, Who is running a company or country people view and feel different about everything.

I was simply pointing it out to you, since once you know that 'X' is required to run software which requires the cartridge to be disabled, the problem of 'f***ing MEMTOP sucks because it's a cart' cannot really be presented as a criticism of SDX. You can feel differently about whether having to prefix a program name with 'X' is acceptable or user-friendly or not, but the matter of applications being able to run perfectly well with the cart disabled and with MEMLO in the expected location is not subjective.

 

From a usability point of view, perhaps it would have been better to have the library (i.e. the ROM) disabled by default and enabled only when the user a) runs the application cart (which is also under the control of SDX), or b) runs a native SDX binary which requires the library. This would certainly have prevented a common problem new users encounter (namely, that they wonder why applications which require $A000-$BFFF to be RAM will not run properly without the 'X' command). But the solution there is to consult the manual. :)

2 hours ago, Stephen J Carden said:

However the X.com in SDX does turn $8000 to $ BFFF from the bank switch cart off so a com file can use or run in that space but the program now running can no longer use a JSR into a dos subroutine or be certain that dos info is there.

The SDX cart itself maps at $A000-BFFF, but X will also disable any underlying 16K cart (which would reside between $8000-$BFFF). The matter of the running program no longer being able to JSR into the SDX library ROM after being launched with 'X' is a non-issue, however, since no software which needs to be launched with 'X' would be aware of the SDX library when it was written, and no software which requires the cartridge to be disabled would sanely attempt to JSR into said cartridge even if the application were designed with SDX in mind. Almost exclusively, software which accesses the SDX library is written as a relocatable SDX binary which does not require 'X' (and therefore can run perfectly well with cartridge ROM occupying $A000-BFFF), and since said relocatable application is designed to run with a lower MEMTOP and can avail itself of many public functions in the library, the negative effects of there being 8K less usable base RAM for such relocatable applications is mitigated.

 

Non-relocatable applications may access the library if they wish, however; there are kernel entry points in the $7xx area designed to facilitate this (the application may enable and disable the SDX ROM, find the location of a symbol, etc).

2 hours ago, Stephen J Carden said:

One of the Functions That only SDX has very right is a way to relocate dos JSR from under the OS or the subroutines starting $C000.

Indeed, and this symbolic linking loader requires the symbol table in ROM at $A000-BFFF. Can't have your cake and eat it, unfortunately. :)

2 hours ago, Stephen J Carden said:

Do not get me wrong I like SDX, I like SpartaDos from way back in the version 2.3 days. For the most part I will use whatever works. If there is nothing out there to get the job done. I will write what I need.

I wholly agree there, but as enjoyable as it would be to write a completely new disk operating system for the 8-bit Atari, I'm at a loss on how one person could reasonably improve on what was already accomplished with SpartaDOS X (in its modern DLT incarnations) and Sparta 3.x before it. Recently, I had no choice but to write an original A8 DOS which uses the FAT file system exclusively, since my SIDE3 loader needed to provide applications with a self-contained proprietary DOS environment which is topically compatible with DOS 2.5 and Sparta 3.x (it implements COMTAB, the command line buffer and parser, and the full extended XIO function set of SpartaDOS). But I am a long way from positing this FAT DOS as a serious alternative to existing 'daily driver' solutions, and even if I had the time and inclination to create a 'novel' general purpose DOS for the A8, I would probably constantly wonder why I was bothering in a world where SDX already exists.

2 hours ago, Stephen J Carden said:

Do not think a compiled code can not be turned back into source and have it come back at you.

Ah - so this is the real reason that 'f***ing MEMTOP sucks'. ;)

2 hours ago, Stephen J Carden said:

You are a big part of that FlashJazzCat but one of your programs that flashes hardware could have one JSR change to a chip rendering hardware useless. You know Pull the hardware and reprogram from scratch. So the one change that is needed is a hardware lock switch to prevent this.

Ultimate 1MB has a software flash lock that you can enable in my firmware. When that lock is set, no flash ROM programming can take place at all, period.

2 hours ago, Stephen J Carden said:

I hope this never happens but I am sure there is some teenager wanting to mess up dad's vintage hardware.

Sure; there's one on the forum. Well, not a teenager but he will go to the ends of the earth and back again to find a corner-case which makes Ultimate 1MB crash. :D

2 hours ago, Stephen J Carden said:

This very reason is why so much of our Windows Software Computer spend so many processor ticks on Anti Virus Utility's. This is also why my updated toolkit has a space that can hold a crc value. This can do two things Stop a mod to a program and tell the user there is a problem. 

It's one of the appealing aspects of retro computing that we need not write every application with the mindset that it is potentially under constant attack by malware. CRC is very useful to verify data integrity in critical operations (firmware flashing and the like), but in the matter of IP protection and 'anti-tamper' technology, anyone who wants to overcome checksum mechanisms can do so in twenty minutes with a debugger and a reasonable amount of skill (and as you say yourself: compiled code can be easily disassembled).

Edited by flashjazzcat
  • Like 2

Share this post


Link to post
Share on other sites
18 hours ago, flashjazzcat said:

From a usability point of view, perhaps it would have been better to have the library (i.e. the ROM) disabled by default and enabled only when the user a) runs the application cart (which is also under the control of SDX), or b) runs a native SDX binary which requires the library. This would certainly have prevented a common problem new users encounter (namely, that they wonder why applications which require $A000-$BFFF to be RAM will not run properly without the 'X' command). But the solution there is to consult the manual. :)

Reading always helps and one might detect not only how to use the X command but also the COMEXE.SYS to help out automatically. Programs known to be in need of the X command carrying the extender EXE will then be started the right way. Please see also the remark with MENU in chapter 4.47.1 as it behaves a bit different here.

 

And nearly forgotten to mention: It is described in the chapters 2.15, 2.16, and 2.17 being part of the 'Introduction To SDX' how to handle programs.

Edited by GoodByteXL
additional info
  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, GoodByteXL said:

Reading always helps and one might detect not only how to use the X command but also the COMEXE.SYS to help out automatically.

True, but I don't think telling a user predisposed to finding fault with the product that they should install a driver to run programs will get the point across. :)

 

The documentation is, seriously, another of SDX's highlights.

Edited by flashjazzcat
  • Like 1

Share this post


Link to post
Share on other sites
On 11/30/2021 at 6:57 AM, janzh said:

I was searching for an assembler to develop on original hardware. I found Fast Assembler for Sparta DOS X by Marek Goderski from MMMG Soft (Free MG) from 1995 (!!!).

 

I was impressed because the assembler has the following features:

  • Support of SpartaDOS X and Atari DOS object files
  • Support of relocatable SpartaDOS X blocks
  • Support of SpartaDOS X symbols
  • The maximum file length of the source code and object data only depends on the file system, as it is a real file to file assembler

 

I ask Marek for sources but they are not available anymore but he gave the Fast Assembler to the Public Domain. So I started to disassemble it, refactored the source, wrote some examples, and add documentation with tutorial. Now I think it is a nice development package especially because JFC allowed me to add XEDIT.

https://github.com/HolgerJanz/FastAssembler

 

Fast Assembler is fully compatible with Quick Assembler, but is not compatible with MAC/65 or Atari Assembler Editor. The Fast Assembler syntax is supported by MADS the 6502 cross  assembler (Fast Assembler can assembled using Fast Assembler itself or MADS). MADS is available for macOS, Linux and Windows (https://github.com/tebe6502/Mad-Assembler).

 

So I hope other people will also have fun with this package.

 

To try this package be myself I have developed a game for the ABBUC Software Contest 2021:

https://github.com/HolgerJanz/VARIUS

 

Everything was developed using an Atari 800XL with Ultimate 1MB upgrade and Side3. The emulator Atari800MacX was only used to test the package on different configurations.

 

Regards

Holger

 

BTW - Next step is to port it to SpartaDOS 3 compatible so one can cross develop from SpartaDOS 3 to X and vice versa.

 

Hi Jan!

         This already is out there but that was not documented for this process.

   The RealDos ToolKit Source I published will do that!!! CrazyBonz Would you please send Jan In a PMessage unless there is a big demand for it. If so I will get another message posted with that info.

 

This is for everyone not just Jan.  It takes a ton of equipment and testing to be certain a DOS is ready for most anyone use. This is why ILS (ME and CrazyBonz) do not give dos source code out as a general practice. Working on and maintaining a Dos is a Bitch.  Back when The XL & XE Atari's came out DOS's only had to deal with was SIO Devices and PBI devices were for the most part Black Box, MIO, and Supra Harddisk and its update KPI. Every new bit of new hardware makes that testing part of writing new programming gets more complex. A lot of new hardware has started making SDX for that hardware. This approach is for the most part the only way to do it.  Now for myself I try to by two or more of everything. This is how CrazyBonz and myself do our testing. 

 

Everyone Have a Wonderful day!

Steve

Share this post


Link to post
Share on other sites
On 12/2/2021 at 5:05 AM, flashjazzcat said:

Fixed that for ya. :)

That is very dangerous to do for that matter undo THAT. The Toolkit has a program that can make changes certain values if a program is looking for version values in $700 and $701.

 

Stephen J. Carden

Share this post


Link to post
Share on other sites
4 hours ago, Stephen J Carden said:

That is very dangerous to do for that matter undo THAT. The Toolkit has a program that can make changes certain values if a program is looking for version values in $700 and $701.

Steve - read this:

 

https://www.urbandictionary.com/define.php?term=FTFY

 

I don't use RealDOS and I have not made any changes to it.

 

I'll obliquely cover a couple of points you raised in your email as well since you bring up the matter of the DOS signature at $700/701, and this may be of general interest.

 

My 'SIDE Loader' has always (since 2015-2016) put 'L' at $700 and the major/minor revision number at $701. This had the unfortunate effect of making it necessary for applications to explicitly check for 'L' and react accordingly once the FMS had implemented subdirectory handling functions. I could not present 'S' at $700 since only a tiny subset of SpartaDOS CIO functions were implemented, and no kernel variables or entry points whatsoever. Even now, with SIDE3's much more advanced loader which implements an almost exhaustive subset of SpartaDOS CIO functions (albeit pertaining to FAT instead of SDFS) and even some kernel variables and function calls, the fact many kernel variables and jumps are still absent would seem to make impersonating Sparta by placing 'S' at $700 a risky proposition. And that's unfortunate, since if $700 read 'S', tools like RWTEST would drop straight back to the CLI on completion instead of sitting there waiting for the user to press a key before returning to DOS (since RWTEST can't know that it's running on a CLI DOS which will not immediately clear the screen before drawing a menu).

 

The Ultimate 1MB clock driver I wrote a couple of years ago and told you that you were welcome to bundle with RealDOS is compatible with Sparta 3.x, BW-DOS, and - obviously - RealDOS (by looking for the 'R' at $700 which you accuse me of changing). Here's the code which identifies the host DOS:

.proc Start
	lda $700
	cmp #'R'
	beq isRealDOS	; if this is RealDOS, ignore the version number	
	cmp #'S'
	bne notSparta
	lda $701
	cmp #$40
	bcs notSparta
	cmp #$30
	bcs isSparta
	
notSparta
	ldax #txtNotSparta
	jmp PutString
isSparta
	lda $703	; see if this is BW-DOS
	cmp #'B'
	bne isRealDOS
	lda $704
	cmp #'W'
	bne isRealDOS
	dec BWFlag	; remember we're running BW-DOS

BW-DOS takes the interesting step of placing 'BW' at $703 instead of replacing 'S' at $700 with a proprietary value. It strikes me that RealDOS - by placing 'R' at $700 - hides itself from any tools which aren't 'RealDOS aware' but which are attempting to configure themselves for a command-line host DOS.

 

In any case: what you wrote about the RealDOS toolkit programs being broken because $700 no longer reads 'R' is entirely moot, since I can assure you that no-one has changed anything at all.

Edited by flashjazzcat
  • Like 1

Share this post


Link to post
Share on other sites

Hi Steve,

 

My sincere condolences I'm sorry for your los.


Thanx for the info. I did not know. Maybe you have some links to more information about RealDos ToolKit Source.

 

Holger

Share this post


Link to post
Share on other sites
10 hours ago, Stephen J Carden said:

Every new bit of new hardware makes that testing part of writing new programming gets more complex.

I'm curious to know why this is. When Ultimate 1MB/SIDE was released and the APT partitioning system adopted, MYDOS, SpartaDOS X, SpartaDOS 3.x, BW-DOS and others all worked without any alteration whatsoever (and no onus placed on those maintaining said disk operating systems to test anything at all) precisely because the PBI mechanism is entirely abstracted from the disk operating system. All DOS sees is a set of large disks, accessed by the same SIO functions (read/write/get PERCOM/etc) one would use to access a floppy disk, and DOS need not concern itself in any way with partitioning software, etc. The only thing RealDOS had to do to fully support SIDE/U1MB HDDs was bundle the ULTD.SYS driver, which is already written (and even that's not needed if you use a software clock or an RTime-8). As far as I know, even vintage mass storage devices like BB, MIO, etc, place no responsibility on DOS to handle IO any differently.

Edited by flashjazzcat
  • Like 1

Share this post


Link to post
Share on other sites
8 hours ago, flashjazzcat said:

I'm curious to know why this is. When Ultimate 1MB/SIDE was released and the APT partitioning system adopted, MYDOS, SpartaDOS X, SpartaDOS 3.x, BW-DOS and others all worked without any alteration whatsoever (and no onus placed on those maintaining said disk operating systems to test anything at all) precisely because the PBI mechanism is entirely abstracted from the disk operating system. All DOS sees is a set of large disks, accessed by the same SIO functions (read/write/get PERCOM/etc) one would use to access a floppy disk, and DOS need not concern itself in any way with partitioning software, etc. The only thing RealDOS had to do to fully support SIDE/U1MB HDDs was bundle the ULTD.SYS driver, which is already written (and even that's not needed if you use a software clock or an RTime-8). As far as I know, even vintage mass storage devices like BB, MIO, etc, place no responsibility on DOS to handle IO any differently.

i use APT and like it very much. With my U1Megs and Side, Side2, and Side 3 I am not aware of any bugs in Firmware or Support Files. Now if the people who maintain that hardware I would like to see these changes. Battery Backed Ramdisk Support and a hardware locking process. These are not bugs just updates that are need in my view.

 

Steve

Share this post


Link to post
Share on other sites
9 hours ago, janzh said:

Hi Steve,

 

My sincere condolences I'm sorry for your los.


Thanx for the info. I did not know. Maybe you have some links to more information about RealDos ToolKit Source.

 

Holger

The link you are requesting is on my web site at this location. http://www.realdos.net/realdos.html  CrazyBonz has the most current RealDos toolkit and he can tell you how to get that that source. I would would prefer that information be in a private email. Thank you for your kind thoughts on my wife she was a very special person.

 

Thanks Steve

Share this post


Link to post
Share on other sites
11 hours ago, janzh said:

Hi Steve,

 

My sincere condolences I'm sorry for your los.


Thanx for the info. I did not know. Maybe you have some links to more information about RealDos ToolKit Source.

 

Holger

i have a new email address. The [email protected] is no longer in use.. Private email needs to go to sj carden 7a @ gmail.com. Just remove the spaces and I will get it.. I now have fiber optic 1 gigabit connection and 5 fixed ip's. I am planning to Bring my website back to my house. Most all of my source has tons of documentation with in them. Send me an email and I will help you with why and how I did things.  I published the RealDos Toolkit for just what you want to work on. I use my own cross assembler but there is no reason the .s files can be ported to your assembler.  It is my wish that people who want to program have documented source to work and learn from.

 

Take care and enjoy. 

Share this post


Link to post
Share on other sites
5 hours ago, Stephen J Carden said:

i use APT and like it very much. With my U1Megs and Side, Side2, and Side 3 I am not aware of any bugs in Firmware or Support Files. Now if the people who maintain that hardware I would like to see these changes. Battery Backed Ramdisk Support and a hardware locking process. These are not bugs just updates that are need in my view.

 

None of that addresses the question I asked in any way. And U1MB already has a flash-lock.

  • Haha 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...