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!
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
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.
tried loading them with direct XEX load under Atari 800 Win
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.
Is there somewhere you can put some signature bytes that won't change with any future releases you make?
Or I could check for the bytes that you changed for, say, the dead-end bug because I bet that's not likely to change.
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".)
Another interesting bug that Wade found: it crashes if people are too close to the road. He discovered you needed spacing:
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.
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:
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.
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.
Did you develop it using some Version Control System ike CVS, SVN or Git? Are you willing to publish the source code?
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).
I am unable to interact with certain services with ICET that I can with FlickerTerm.
I am able to use this stuff with FlickerTerm by setting "CR out" to "CR + LF".
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.
Since MyBIOS on stock atari disables internal OS and wants bit 0 of PORTB being false, I replaced all PORTB values in the binary.
So what makes for a good BBS experience is macros.
Hi, what year is this? I guess it's time to address these requests. Here is the long awaited alpha 7
PORTB bit 0 is no longer modified by Ice-T, fixing compatibility with systems that enable OS RAM, such as MyBIOS.
To use macros, note the new menu entry Options > Macros. It will display 12 empty 'slots', each of which can be set to a letter or number of your choice and then filled with a macro of up to 64 characters of text.
The text entry field accepts only plain text, but special characters may be encoded within the macro as follows:
To insert a control code, the percent symbol '%' can be used. The character immediately after '%' will be sent stripped of its upper 3 bits, so %X or %x will send Ctrl-X (ASCII code 24) and %[ will send Esc (ASCII code 27). To send the percent sign use '%%'.
To insert an arbitrary byte use '$' followed by 2 case-insensitive hex digits. To send the dollar sign use '$$'.
To activate a macro in Terminal mode, hold down START and type the corresponding key.
Note that in previous versions the START button caused plain key codes to be prepended with Esc (so pressing START-C would transmit Esc c), mimicking the Meta key that was present on keyboards of some old terminals. This feature remains available for any key that is not assigned to a macro.
Enjoy! And as always let me know if there are any problems.
Actually I have a better idea for you. I'm attaching SPLAT.BAS. This was the very first proof of concept I did in 1992 or so before starting Ice-T - a dead simple Atari BASIC program that opened the serial port in 300 baud and let you communicate with whatever's on the serial port (modem in my case). What you can do with it is play freely with the XIO commands, twiddle the settings and figure out what's wrong with your setup.
Open the PRC manual (it's on Atarimania if you don't have it), read about the XIOs to understand the port opening sequence, and try to figure out what's wrong. I believe I enabled ATASCII/ASCII translation here so I wouldn't need to code the translation in BASIC, so try disabling that and see what happens (you'll have to press ctrl-J or ctrl-M instead of Return to send an end of line, but it should still *work*). In Ice-T this is of course disabled. Also if you change the baud rate to 9600 you will lose data but you should at least see parts of valid text. Let me know what you discover.