Jump to content
IGNORED

Was SpeedScript ever made into a Cart?


mytek

Recommended Posts

I'm fiddling around with making an EPROM with 4 languages on it, and thought that SpeedScript would be cool to include as one of the selections. So I remember something about someone putting SpeedScript in a Cart, and if so, was wondering where I could get the ROM file for that?

 

Link to comment
Share on other sites

I have no idea.  But Speedscript was a great word processor and I did a lot of reports on it for school.  It even allowed for adding an extra dot (or more) between characters.  So, if you used Speedscript correctly, you could hide the actual shorter length of your report from the teachers.  The teachers expected a page to have x number of words and not a greatly reduced number of words because you added a single extra dot between each and every character.  That one dot really added up to quite a savings for a ten page report.   ?

 

  • Like 2
  • Haha 3
Link to comment
Share on other sites

Yeah I used SpeedScript to write weekly reports at a place I worked back in the mid 80's. It was really all that I needed at the time. That version I had typed in from a magazine and then saved to floppy disk. Being very compact, it took no time at all to load in from the disk. After a while, several other people that I worked with started using it as well to do their reports.

 

Link to comment
Share on other sites

Out of curiosity, I loaded my Speedscript 3.0 disk and the Speedscript 3.0 file is 66 sectors long.  Going from memory, I think 3 bytes are used by the disk operating system.  So, it's between 8,125 and 8,250 bytes long.  Assuming it's less than 8, 192 bytes long, I don't know what would be required to get it to run off a cartridge.  My guess is that it would need to be re-compiled to run as a cartridge at A000.

  • Like 1
Link to comment
Share on other sites

Source code is available at https://www.atariarchives.org/speedscript/.  As I recall, it uses a custom charset, so there are memory usage considerations; it may take a bit more effort than just recompiling, setting INIT and RUN addresses and calculating the checksum.

 

Just did about a 30 second scan of the source code.  As written, it assumes that the available memory is above the program; converting it to run from the Left Cart memory area will require some degree of review.  There is a custom character set, and a boot loader stub.  The boot loader is likely not needed if it's converted into a ROM image.  It is probably in the art of the possible to convert it to a ROM image without too much effort (famous last words).

  • Like 1
Link to comment
Share on other sites

17 hours ago, Wrathchild said:

Wouldn't running it on modern faster SD/Compactflash solutions be just as good a using a Cart?

I actually need it to be an alternate 8K ROM for the other 3 languages I'll have on the EPROM, which will be 1 of 4 selected languages.

 

14 hours ago, reifsnyderb said:

Out of curiosity, I loaded my Speedscript 3.0 disk and the Speedscript 3.0 file is 66 sectors long.  Going from memory, I think 3 bytes are used by the disk operating system.  So, it's between 8,125 and 8,250 bytes long.  Assuming it's less than 8, 192 bytes long, I don't know what would be required to get it to run off a cartridge.  My guess is that it would need to be re-compiled to run as a cartridge at A000.

As I stated my usage really requires it to be able to fit into 8K. This of course would also mean that it could be loaded into one of the U1MB slots as well.

 

13 hours ago, David_P said:

Source code is available at https://www.atariarchives.org/speedscript/.  As I recall, it uses a custom charset, so there are memory usage considerations; it may take a bit more effort than just recompiling, setting INIT and RUN addresses and calculating the checksum.

 

Just did about a 30 second scan of the source code.  As written, it assumes that the available memory is above the program; converting it to run from the Left Cart memory area will require some degree of review.  There is a custom character set, and a boot loader stub.  The boot loader is likely not needed if it's converted into a ROM image.  It is probably in the art of the possible to convert it to a ROM image without too much effort (famous last words).

This is beyond my expertise, so any help in making this work is appreciated.

 

Link to comment
Share on other sites

I've been lurking with interest in this thread and did have a look thru the source code, assembled it and have come to some conclusions. It's built to load and work at 0x1F00 with the tail of it being the start of the text under construction. It definitely has self modifying code and I can't know every instance so it's best to not have it as a cartridge without wild and exhaustive overhaul of these obstacles. Far better then to make it load itself to where it is supposed live and work, take the 8K hit at the upper end of memory buffer. I can do that after taxes and auto repair aren't the main issues. Until then anybody else can do the same thing. Only issue is that it steals DOSVEC for itself and you won't be able to get back out of it without a power down. You should be able to select a different cartridge before shutdown though. And we should allow it to boot DOS as well. Any other issues before I start work on it? There is room to use a code mover to place the code in it's old home and fire it up - it can be made a cartridge of without too many headaches if this shortcut method is allowed. Reassembly to the cart area to work from will involve being in love with this code and the application, and endless retries when it fails to work properly in it's modified form. I've never seen it before so I'm not so much in love with it. But it is possible, just not from this guy. By late next week anyway, I should have something for you to give a test run.

 

PS - will this be a supercart that can be turned off entirely because that option removes the 8K hit at the top of memory and also complicates the loading code to a certain degree. For instance which write to what address will turn off the cart? Of course this won't work like that at all if code is in the slot for BASIC and it doesn't shut off at all, it will try and fail to shut off is only downside. So we might want to think of the method to use if it's available? SDX might be different from Atarimax, etc., I don't keep up on the all toys that are out there as well, that's where your opinion matters more than mine.

Link to comment
Share on other sites

Hi @1050 - My proposed usage will be as a replacement for the built-in Basic ROM of a 800XL (same as the 600XL, and the XE series). I still plan to have Basic, and will simply use a 4X bigger ROM (32K EPROM) so that I can select which 8K segment is enabled by manipulating the upper 2 address bits. I have implemented a method of doing this which will also automatically execute a Cold Re-Start function after a new selection has been made. So in essence it will do what a power cycle does, without actually turning off the power.

 

Speaking of taxes, I'm in the midst of doing mine :mad:

 

 

  • Like 1
Link to comment
Share on other sites

I’ve converted the source to atasm (not much change needed) and built a working executable from it. 

 

My plan is to copy the two self modifying routines down to page 6 at init and tweak the code a bit to remove two more writes to program memory.

 

That leaves page 1F for variables and $2000-$9FFF for text. 

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

I like the apology in the source code, where the author acknowledges that he probably should have used a label instead of an absolute address - where the program toggles one bit in the char set to make non-printing spaces visible / invisible. (Search for ONOFF)

 

  • Like 3
Link to comment
Share on other sites

3 hours ago, 1050 said:

I certainly admire your courage Eyvind, don't forget there is some 5 (6?) pages of variables and buffers that need to be ram based starting at line 610 of the source file named data. So 0x1F00 is now 0x2400 or similar. Cut, paste, and pray brother.

Oh, I didn't realise those were so big, but that just changes my estimate of where the text will start. $1F00-$2408ish will be variables, text starts at $2500 (it starts at the next page after the variables, and I'm not sure if that's just Charles Brannon being quirky or if there's a technical reason it needs to be on a page boundary). I think there are only about 128 extra bytes that need to be copied to RAM, so I might put those before the variables instead of in page 6 since that space will otherwise be wasted anyway.

 

Another thing I considered was to put the variables in $Cxxx, which unfortunately sacrifices non-52KB-expanded 400/800 compatibility. The advantage is that it removes hardcoded memory addresses from low memory, meaning it should be possible to start the text after MEMLO instead of hardcoding the location. You'd be able to create crazy big documents if you were willing to save to cassette!

  • Like 1
Link to comment
Share on other sites

4 hours ago, David_P said:

I like the apology in the source code, where the author acknowledges that he probably should have used a label instead of an absolute address - where the program toggles one bit in the char set to make non-printing spaces visible / invisible. (Search for ONOFF)

 

Thanks, I didn't catch that (because the address is hard coded). That means the character set has to be copied to RAM as well, meaning 1KB less memory for text. Oh well.

Link to comment
Share on other sites

2 hours ago, Larry said:

Curious... Can the hard coded addresses be changed to labels in the reassembly? And would it actually help?  

I've changed the code to add a label for the charset and use that to calculate the target address. Using a label means that making space characters visible won't overwrite something unexpected in memory if the charset has been moved, but the charset still has to be copied to RAM.

  • Like 1
Link to comment
Share on other sites

Technically yes, Larry and it can be a godsend too. But we are always up against the missed one like the following example.

 

please move CHRYSAVE from support source file
0520 CHRYSAVE .BYTE 0

 

as it is probably going to be rom and tucking something away in rom like that just doesn't work.  And one little missed one means all your hard work doesn't work while you don't have a clue about why not. One of the steeper challenges and also a source of great personal reward when victory has finally been achieved.

 

My approach to making it a 0xA000 rom is going to be to pad zeros where they aren't such that the rom move portion into ram won't be detectably different from a disk load version and then roll the dice. Might work out.

 

I must say I really like how this program has a lot fans rooting for it.

  • Like 2
Link to comment
Share on other sites

Thanks, CHRYSAVE is noted. The others that I've found are DIRNAME, SCRCOL, TEXCOLOR, and JDOS, in addition to the self-modifying UMOVE and DMOVE routines.

 

The new memory layout is going to be $1F00 for those, charset at $2000 (like the original), then variables after that. The difference from the original is that most of the code is moved from between the charset and the variables to $A000.

 

There will be slightly less room for text, but it's possible to make more by moving some of the variables to pages 1F and 6. Alternatively, moving the RAM-based stuff to $Cxxx would leave all of low memory for text.

Link to comment
Share on other sites

Can the self-modifying elements (for memory copying) be re-written to use ZP locations / ZP indexing instead?  It would reduce the RAM footprint, and perhaps simplify the conversion since those routines could then remain in ROM.

 

As well, are the $1F00 elements still necessary once converted to a cart?  Stealing DOSVEC for init when you've got the cart init vector; checking memory footprint to see if the program is already loaded... are those needed once the program is moved to ROM?

 

Link to comment
Share on other sites

Possibly, but I'd like to make as few changes as possible to the program, especially since the comments say that the copy routines self-modify for speed (it's the brand!). It might be possible to scrap DOSVEC entirely, but I'm not sure how cart init works when DOS boot is enabled, so some documentation reading and experimentation is still needed :)

  • Like 2
Link to comment
Share on other sites

1 hour ago, 1050 said:

I must say I really like how this program has a lot fans rooting for it.

Me too :)

 

For me it was always about simplicity, while not giving up usability in a basic word processor/editor. I always liked the true descenders as part of the special font that was used, and really didn't miss the fewer lines as a result of this decision. Excellent readability, especially with the choice of the gray background color behind the black text ?

 

screenshot.png.54b953e95a5b0824c1049fc7d66ac675.png

 

This program deserves to share one of the 8K slots in a U1MB.

 

  • Like 3
Link to comment
Share on other sites

8 hours ago, mytek said:

This program deserves to share one of the 8K slots in a U1MB.

Quite fitting that @flashjazzcat has listed Speedscript as an inspiration for his (much more advanced) Last Word word processor.  I believe he said it was typing in this code that helped him understand layout and structure of a large application in 6502.  If I am misremembering this, I apologize.

  • Like 1
Link to comment
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...