itaych

Transfer > Xmodem send.

This is really annoying. Did the authors of SpartaDOS just assume that no one will ever want to use that extra memory? Isn't there some system call that could tell DOS to release that memory, and reload that code from disk when the application exits (like most other DOSes do)?

Considering the fact that I'm out of memory, not much! I did want to iron out some things and make an 'official' (i.e. not alpha) release, but I haven't found time to deal with it in years and the memory issue has been frustrating me. I think in the alpha release Ymodem-G will hang because the popup notification window with the warning message, will cause a buffer oob check to fail - probably no one uses it so no one cares, but it's the sort of thing that I wouldn't let slip by in a real release. @flashjazzcat, I've reviewed the sources, all single use init code is overwritten after running.

There is a startup routine that gets overwritten but most of the init code must remain resident because Ice-T was designed to survive a push of the Reset button. But perhaps some of it is single use, I'll look into it. Thanks!

An extra 3 kb could be great, though I'm worried that (a) these addresses are not necessarily correct for all OS versions including third party ones, and (b) I'll break SDX.

Sorry if I sound like an idiot, what are these overlays you speak of? And where did you find information on how TurboBASIC works? Did they publish example code for this technique? Thanks.

This might be possible if I hardwired Ice-T to run with a specific serial port type, but as it is there's no choice but to use the standard R: device, and there's no way to tell it to disable interrupts and work in polling mode.

This may make sense when the only interrupts in the system are the VBI and the keyboard, but in my situation I need maximal performance while there is constant I/O going on, and as far as I understand there is an interrupt for every single byte incoming over the serial port. This happens >1000 times/sec and I worry that adding even the slightest overhead will slow the system down noticeably. I'd have to see what the ROM does and implement the same thing myself. (it might just call the R: handler which is already in RAM so perhaps this is not so difficult.) Also any IOCB call to disk/printer/serial/keyboard (gotta love those clicks) must also switch PORTB, and must itself not be located in the OS RAM - so this is definitely not a "set and forget" solution with zero restrictions. As for SDX, well in my scenario the extended RAM is already taken so SDX gets completely ruled out. Not sure how happy the users would be about that.

I'm considering doing a little more work on Ice-T. Trouble is, I'm out of memory. The only remaining unused memory is that under the OS ROM and I'd like to make use of it. Why did I never use it before, you are surely asking? The reasons are several: I didn't need it. XE banked memory provided far more than what was necessary and was the easiest to use. I didn't know how to do it without instantly crashing the system. Even if I did it, I wouldn't know what areas in memory would be safe to use without breaking disk, printer and serial port I/O, all of which must remain available. The OS VBI routine needs to keep running, the keyboard interrupts need to be serviced as usual. There are also probably a few things I've forgotten or that I'm not even aware of that need to keep working. Some working environments (various DOSes, custom OSes, etc) themselves use the XL memory for their own purposes, making questions 2 and 3 even harder to answer. I also need to worry about not breaking them. Well, issue 1 is no longer correct. For issue 2 I could probably do some research and figure it out (I'd still appreciate getting the answer here), but 3 and 4 have me stumped. Of course if these issues have been discussed elsewhere I'd love a link. Cheers

Ok, I've gone over the git version. I can see that a lot of work has been done to make life easier for map editors, but I feel this is at the expense of keeping the game as close as possible to the original. First, when starting the game a search for the hideout location is performed. This makes sense (because the map may have the hideout at a custom location) but since the map is huge this takes a noticeably long time. Why does this have to be done at every game start? Do it once at initialization, store the location and be done with it. It's not like the hideout is going anywhere. Second, the cop positions are now generated randomly at game start time, as opposed to the original where their start locations were fixed. This is perhaps required because the fixed locations may be inside a building in case of a custom map, but I don't like it. It changes the original game's feel and behavior which is a no-no in my book. Your book may differ of course, but I think the original hardcoded locations should be used, and if they end up on a non-road then search for a road nearby (I think you've already added a routine to do that). Since the hideout - and with it the initial player location - is not fixed, the cop/van positions can be hardcoded as a delta from the player's start position rather than a fixed coordinate. About the reset steal code: your version steals reset only in some cases but not all (Altirra yes, Atari800win no). In general it seems that the git version already contains my bug fixes, so there isn't much for me to contribute directly. I made a pull request with some minor cleanups and comments, but no functional change. If you want to fix the reset steal code please do it yourself (my solution is to also write the reset address to DOSINI and CASINI in addition to the existing DOSVEC. It works but I'm not sure it's the correct way to do it). I don't plan to make further changes but if I do I will continue to post them here because I still like "my" version for its minimalism and closeness to the original. I will however also send update requests via git if they're relevant.

Here is a wrap up of my latest changes: Bugfix: The game with my modified source wouldn't run at all on Atari800Win, and probably most other platforms including real hardware. Bugfix: The title screen demo would hang if the car hit a dead end (in case of a modified map). Cleaned up the code a bit, removing many stray blank lines. Added getaway_halfdone.plf . This is taken from one of Mark Reid's original disk images and appears to be a work in progress version of the map. It's included for historical interest. Documented the available sound effects. Surprise surprise, there's an unused sound lurking in the data tables! It isn't actually very exciting but if you want to hear it, in the source code find the label HITDOL and two lines below it replace LDA #129 with LDA #97, and run over a dollar sign. (Note that this release has nothing to do with the "ruined" versions from my previous comment. I wonder if anyone found them remotely amusing..) Hey playermissile, I'm sorry for being annoying and not cooperating with your efforts to do this properly. To be honest I've never worked with git, guess it's time to start. I will try and merge my fixes with your repo soon. I'll PM you if I need help. Thanks. Getaway_20171205_itayc.zip

You're right, I'd only tested under Altirra so I thought I was fine, but in other emulators (probably real hw too) the game will fail to boot in all the versions I've posted here except the first (the "pirated executable"). The fix is to remove the RTS at the end of the function STEAL (which steals the reset vector) and also write the reset address to DOSINI. Attached are fixed versions of my two pet abominations. getaway_ruined.xex getaway_diamonds_are_forever.xex

You must have written that before you tried playing these versions...

Whee, this is fun! getaway_ruined.xex getaway_diamonds_are_forever.xex

I think you're missing the point of what I'm doing here. I'm not releasing new binary versions of the game, why would I do that? These releases play exactly like the original. The idea is that you take my updated source code, replace the file getaway.plf with your own map, build, and release the xex file. Things like checking signature bytes are hacks intended for cases where the source is not available, that's no longer the case here. Also you'd need to change a couple of equates in the source code to move the hideout, there is no code that scans for the "H". (I added these equates, before them the hideout location was, well, hidden - in various "magic numbers".) The characters used for people happen to be part of the set of characters that the cars are allowed to drive on. This is because the game allows driving on any character in the range $7x, which includes the blank road (1 char), the gas station, hideout, dollars, prizes, stoplights and roadblocks (2 chars each). However this leaves 3 additional unrelated characters, which happen to be the graphics for people. The hang (an endless loop, not a crash) occurred because, since that character is interpreted as a road, you created an invisible dead end when placing these characters adjacent to a real road. The solution is to change the code to allow driving only on the correct characters. It's a little uglier and takes a few more cycles, but the game isn't exactly starved for CPU time. The fix is attached. Getaway_20170204_itayc.zip

This one won't crash if a cop or van hits a dead end, allowing more flexibility in level design. Enjoy Getaway_20170203_itayc_2.zip

Here is another version. This includes my previous patch, plus allows for changing the hideout location, which was previously hard-coded. This should aid people who are editing the map. Getaway_itayc_20170203.zip

Woops, there's a bug in my "clean" version (Getaway_20170129). The source contains a routine RNSPOT that picks an empty spot on the map on which to place a prize, roadblock etc. This routine is hard-coded to suit a fixed playfield address, regardless of the value of PLYFLD. It will only work correctly for PLYFLD=$3000, which is the case in the "pirate_executable" only. In the cleaned up version it's moved to $4000. There are two ways to fix this: Method one is to remove these two lines just under the RNSPOT label: SEC SBC #$10 This is actually what Mark's code in disk M11 (where PLYFLD=$4000) looks like. It will work, but personally I don't like it as it will still break if PLYFLD is moved again. Method two is a patch. Replace this code: RNSPOT LDA RANDOM ;pick spot AND #~00111111 ORA #~01000000 SEC SBC #$10 STA TEMP+1 with this: RNSPOT LDA RANDOM ; pick spot AND #~00111111 ; hi offset $00-3F CLC ADC #>PLYFLD ; add base of map address STA TEMP+1 ...and that should work for any PLYFLD location.

I've managed to get the sources to Getaway to build! The sources are apparently not the final version that was distributed; to get a precise match with the released binary I had to mix code from disks M11 and M14, as well as make some small changes based on the binaries. The binaries I based myself on were a pirated executable version that circulated in the early 80's, as well as the image 'M25 - Getaway 1.1' from this archive. They are nearly identical; the only difference between them is that the disk image loads data at $1000 so it would fit in a 32K machine, but an executable can't load to that address without overwriting critical DOS code; so the executable version loads at $2b00 then adds some code that copies everything to the right place before jumping to the start location. The archive that builds to a file identical to the pirated executable is named "Getaway_20170128_pirate_executable.zip". Once I got that working, I got rid of all the garbage that was needed for creating the 100% identical binary. With code locations taken from the M11 version the game now won't fit in 32K but the relocation nonsense is not needed anymore, making things a lot simpler. Also, some garbage data that was present in the original binaries (the boot sector, plus the padding between the game code and the playfield data) could be removed. The result of this cleanup is named "Getaway_20170129.zip". Both archives behave the same: Extract them wherever you like. On a Windows machine, download the ATasm assembler and copy its binary (atasm.exe) to the 'build' subdirectory and double click the file build.bat. The result will be generated in 'bin'. Non Windows users should build ATasm for their platform, and use the build command in the build.bat file. Enjoy! Getaway_20170128_pirate_executable.zip Getaway_20170129.zip

Ice-T was mostly developed in my bedroom as a teenager with an Atari 130XE. I knew nothing of these three letter acronyms of which you speak and even if I did there was no practical way for me to use them .. During a few years that I continued development (2012-2014 or so) I simply kept a snapshot of every release. I published the source code to version 2.72 (released in 1997) here. It's not very pretty and much of it has been changed or even rewritten since then, but I haven't published the newer sources - and I think no one even asked for them. Perhaps I will with the next major release (any decade now). Ice-T was designed as a VT-100 (now 102/52/ANSI) emulator, not a general Telnet client. The standard behavior for these devices is to send a CR when the user hits Return. It's nice that FlickerTerm allows to change this, at the time I saw no need for this. (Remember Ice-T was written first, I didn't have FT to compare to, and nothing that I tested against needed it.) I wish it were trivial to add this feature, but nothing is simple when your project is written in assembly. The EOL setting you mention governs how Ice-T interprets incoming codes, not outgoing. I've managed to interact with websites and the weather site you mention by using Ctrl-J where you'd press Return. Note that if you want to see what you're typing enable Local Echo.

Sure. Read the "getting started" section of the doc.

My 9 year old loves it! Looks great in wiixl.

This is fantastic. Are there plans to release it as a hardware cartridge?

Always glad to hear from a happy user. Enjoy!

You are probably never going to achieve an authentic looking output from a PC to a CRT monitor, because the real Atari outputs a static 240 line non-interlaced image. So did many early consoles, btw (such as all Nintendo generations up to and including the 64). The only modern hardware I'm aware of that can still do this is the Wii, and indeed it does so when running NES Virtual Console games, but I believe that even WiiXL (Atari emulation on the Wii) - which is surely the easiest way to achieve what you want - does not take advantage of this capability.