Dmitry

p.s. just to let you know, the program always ran in the emulator. Apparently the emulators don't mind the illegal opcodes, but my Atari didn't want to use it.

A few questions or maybe comments, well, lets call them questions. 1. What's wrong with this code: if ((AF1 ==0 || AF1 > 56) && (AF2 ==0 || AF2 > 56) && (AF3 ==0 || AF3 > 56) && (AF4 ==0 || AF4 > 56)) { asm { handdown: ldx #$01 //throw down hand stx $6BCB stx $6BCC ldx #$0 stx $6BC9 stx $6BCA ldx #$60 stx $6FCD //draw balloon ldx #$F0 stx $6FCE stx $6FCF stx $6FD0 } } What that looks like in the asm file is: ldx.z AF1 ldy.z AF2 tya sta.z __261 txa cmp #0 bne !__b99+ jmp __b99 !__b99: cpx #$38+1 bcc !__b99+ jmp __b99 If that looks impossibly small, well it is. It just doesn't contain my asm section labelled handdown anywhere in the file and also the program is borked. However, if I, replace that whole if statement, with this, now entirely hand coded in assembler, it works fine: asm { //if no ballons af frame >0 and <56 then hand should go down, but doesn't check if hand already down. lda #0 sta FLAG AF1CHK: lda AF1 cmp #57 bcs AF2CHK cmp #0 beq AF2CHK inc FLAG AF2CHK: lda AF2 cmp #57 bcs AF3CHK cmp #0 beq AF3CHK inc FLAG AF3CHK: lda AF3 cmp #57 bcs AF4CHK cmp #0 beq AF4CHK inc FLAG AF4CHK: lda AF4 cmp #57 bcs CHKEX cmp #0 beq CHKEX inc FLAG CHKEX: lda FLAG cmp #0 beq handdown jmp HDWNEX handdown: ldx #$01 //throw down hand stx $6BCB stx $6BCC ldx #$0 stx $6BC9 stx $6BCA ldx #$60 stx $6FCD //draw balloon ldx #$F0 stx $6FCE stx $6FCF stx $6FD0 HDWNEX: } Next question. Rasterbars.c doesn't specify pragma cpu, so how does it prevent kickassembler or c from using its default behavior of using illegal opcodes? In another thread I talked about this line of code: BX1 = PLPOS+9; producing some kind of AXS command, that anyway when run on the real Atari, the program is borked. But when I add this : #pragma cpu(MOS6502) Well now the asm file doesn't contain the AXS opcode, and ultimately the program does run. I just want to check, if this is actually a requirement for running on Atarixl, why isn't it in the examples, like rasterbars.c? It seems to me I got pretty far without specifying the cpu, but eventually it caused me a problem, like a gotcha waiting to happen later. Just wondering if perhaps Atari projects should default to not using illegal opcodes? I'm no expert, I'm just sharing it failed until I made the change. Thanks

and i am back from reading the docs. #pragma cpu(MOS6502) looks like that turns off support for illegal opcodes It's not used in the examples for Atarixl platform (e.g. rasterbars.c) , but if the compiler defaults to using illegal opcodes for some basic C statements I think this platform should probably not use the defaults. Anyway, leaving here in case it helps someone, but, seems like this was mostly a detour.

I just replaced the code just now with asm { clc lda PLPOS adc #9 sta BX1 } Now it works. I just found it interesting that I issued such a basic C command and KickC used an unstable opcode that doesn't work on the Atari. I guess it is some optimization leftover from its Commodore roots, as a guess. I definitely wasn't looking for this result, not sure if it is changeable in a config somewhere. Oh well, problem solved, the test now works on my Atari.

Thanks for the suggestions. I find this interesting, and I shoudl have a workaround. I finally tracked it down to the sprite was being drawn off screen, that is why it doesn't appear. I'm using KickC. The DLI and VBI are pure assembler, but I have some code in KickC. This line always caused a 0: BX1 = PLPOS+9; Now, that is curious, so I went into the compiler generated asm. lax.z PLPOS axs #-[9] stx.z BX1 lax.z PLPOS axs #-[9] I don't recognize these opcodes, but I'm not that experienced in assembler, I just get by with what I need for now, it's curious the emulators all ran this, but the real Atari didn't respond. I did a google search, and it is say AXS is an unofficial or extra opcode? Wild stuff. Well I can add in assembler without using KickC, but I wasn't expecting it to do this....do you all think it is in error for using this opcode?

I'd like to ask very generally about Emulators versus real Atari. Essentially I've been merrily making progress on my game, but today I put it on a real Atari. The xex loaded. The man moves left and right on the screen. The program makes extensive use of DLI and VBI, and multiplexing of players. Obviously a lot of that is working, even to show the buildings which use players to add color, and the little man is colored by dli, and the update of the position is in the vbi. But the player0 balloon doesn't show - not sure why, I might assign it to timing, but...probably isn't. I mean it requires very tight timing to do the multiplexing, but not at all if you don't move left and right, in which case hpos0 isn't updated in the position table anyway. No...it is something, but without delving into specifics, are is there any general advice? Like what types of issues you program against an emulator versus the real Atari? Honestly, I thought they were darn near perfect. I guess that was naive on my part?

This is interesting, I have an 800XL that I just installed an upgrade in. It always boots into basic, so I thought the option key was broken. However, I ran across this thread and so I typed in the program and wow, the option key does work. What doesn't work - is disabling basic. Despite the option key being held down, I always go into a basic screen when starting up the computer. Further, if I put an actual cartridge in the machine, such as Assembler/Editor cartridge, then exit from tehre into DOS, then Antonia setup tells me to remove the cartridge. If it just boots into basic, and I then load DOS and go into the Antonia setup (ant.exe) it then doesn't complain about any cartridge, so it recognizes some kind of difference. Nevertheless the machine always boots into basic first, I have to type DOS from the basic command prompt, and upon loading ant.exe, it will never flash the rom. Since Antonia also has a basic rom on it, this may be unrelated to the Atari otherwise. oh well, not to hijack the thread....I was just toying around with the 800xl, trying to see if I can get an atari going while the others are sent off for repairs.....seems I am not so lucky, well, I could've let well enough alone and not installed the antonia, it was working before hand, haha....I am not so wise...

I decided to see what the fuss was all about. Played a few rounds on the Atari, wow, nice game, great job.

oh good, I don't know, I just try to be careful! woot! Thanks all, another problem solved.....

OK, Just a warning - this is not a major update. So, only posting it, for anyone that does enjoy a development blog - and this one is kind of at a weekly status update. I'll make a note when major progress is done.

I think I may have the answer. So, you load ANT.EXE. You put brackets around the one you want to choose, hit Enter. Then Accept.

Dude, thanks for all your help, we are having a communications misunderstanding that may be my fault. So in order to not cause any offense, allow me to very formally avoid any misunderstanding 1) I'm very appreciative of your help 2) I'm not complaining 3) I do not wish you to think I'm asking you for further help But I have a question that has a simple answer, I do not want my question to become unanswered becasue of this "RTM" response. From my perspective it was quite the logic puzzle, to obtain an un-arc program for my mac. To then get a readme.txt that doesn't have readable eol on my Mac, to use regex expressions to replace the EOL characters, to then read the document, which still does not answer my question. That's fine. Anyone that has used the product can answer this in 5 seconds, if someone else, will just tell me, how do you select the slot that you want to use? Thanks Btw, in case it helps anyone, here is the readme.txt that I have read, what I see here is the ant.exze configuration. What I'm asking about, is after I have a few configured, how do I select them later? How do I select the one that I would use? README.TXT: Antonia 4 MB Configuration software This program allows you to configure the Antonia 4 MB extension, i.e. choose one of the 8 available ROMs to serve as the OS and BASIC, and one of the 16 available RAM setups. General characteristics ----------------------- Apart from the usual RAM extensions handled by the PORTB register, that is: ) none 2) 130XE - separate access for CPU and ANTIC 3) Karen 192k - separate access for CPU and ANTIC 4) Rambo 256k 5) Rambo 320k 6) Compy Shop 576k - separate access for CPU and ANTIC 7) Rambo 1088k the Antonia also offers two less usual options: Axlon 2 MB or Axlon 4 MB 9) 2 or 3 MB linear RAM for the on-board 65C816 CPU The Axlon implementation on XL/XE slightly differs from what is known on 400/800. On the original Axlon for the 400/800, due to partial address decoding, the controlling register occupies the areas $0FC0-$0FFF and $CFC0-$CFFF. On XL/XE the register is located only at $CFFF; moreover, it is available only when PORTB bit 0 is set to 1 - or in other words, when the system ROM is on. The Axlon extension can be used in SpartaDOS X just the same way as the regular PORTB extension is usually used there, i.e. for system code, ramdisks and such. The size of the Axlon and linear areas are dependent on each other: there is 4 MB RAM to share, so if you want both enabled, each one will occupy 2 MB. When you disable the linear, the entire memory will get assigned as the Axlon RAM. The linear RAM is accessible using the new (to 6502) addressing modes provided by the CPU. The flasher uses this memory to buffer the ROM contents before flashing. When the Axlon 4 MB was selected, the flasher cannot enable the linear RAM without remapping the banked extension, and this may be destructive for any data possibly already residing there (as ramdisks, resident drivers and so on). This is why in this case you will be asked to switch the memory configuration manually before proceeding. Again, the linear RAM may be used as ramdisk under SpartaDOS X. NOTE: the presence of the linear RAM past the first 64k proved to cause some compatibility problems with some software. The most known program which has a problem with that is MyDOS. If you experience that, please either use a patched version of the program (MyDOS 4.55p) or switch the linear memory off. Using the ANT.EXE setup program ------------------------------- The program allows you to select RAM and ROM configurations as shown above. It also contains the flasher, which enables you to change the ROM contents. The ROM is split in 8 slots; each slot contains two separate areas: one for the OS and another one for the BASIC. Initially all slots are preprogrammed with XL/XE OS (rev. 1.03) and Atari BASIC rev. C. The ROM is generally divided into two halves. Each half contains these 8 slots, which makes 16 slots. But only one half is programmable. The other half is provided for easy recovery in case of bad flash. You swap the halves using the jumper provided on the Antonia board. The preprogrammed contents will be displayed as "XL OS 1.03" (in the configuration menu) and "BASIC rev. C" (= Atari BASIC version C). If a slot contains something different, both menus will by default display its checksum code in hex. As of ANT version 1.2 these checksums are calculated by the ANT.EXE program, it will not rely on precomputed OS checksums. As of ANT version 1.6 a second binary is provided which computes CRC-16 instead of checksums. This is more reliable, but slower, e.g. the initial ROM scan takes about 6 seconds in the CRC-version and about 2 secs. in the checksum version. Also as of ANT version 1.6 the program allows to assign arbitrary names to the slot contents and store them in a disk file which will be loaded at next startup. Using the flasher ----------------- The following information is (strongly) based on the AtariAge post made by Larry (many thanks!). 1) Make an ATR (or disk, or folder on the disk) using either SDX or MyDOS or any other favourite DOS, to hold ANT.EXE. 2) put there the OS ROM files and BASIC ROM files that you want to use. 3) Load the ANT.EXE without BASIC. Under SDX you should use the X.COM command to execute the program (or have the COMEXE extension loaded). 4) When loaded, the program will show you the current settings. The square brackets show which ROM pair is currently active. (Note: you are always using the OS/BASIC pair - you do not pick and choose separately). On this same screen, the type of Atari expanded memory is shown in highlighted inverse: this is the cursor. 5) Initially all slots are filled with the same default ROMs: XL OS 1.03 + BASIC rev. C. 6) If you want to change a slot, press "F": this takes you to the next screen showing all the slot pairs #0 - #7. Note that the slot that is currently active will have the "#" highlighted. 7) Use the up/down cursor keys to highlight the slot you want to change. For example, let us say that you want to change the OS in slot number #3. Press "L" - and the program asks, if you want to load an "O" 10k OS ROM (400/800), "X" 16k OS ROM (XL/XE) or "B" BASIC. Let us say that you want to change the OS ROM to Omnimon XL. 9) Press "O" and the program will show you the contents of the current drive/folder (under SDX) or D1: (under other DOS-es). The OS and BASIC images you want to use should already be there. You must have previously put "OMNIMON.ROM" to that place. 10) Note that the file selector allows you to change drives (press 1-9 or A-O) and navigate through subdirectories, so if it does not show the ROMs at first, do not panic. 11) Use the cursor keys to highlight the desired file and press Return. The program will immediately load that file into the proper buffer position in memory. (Note: nothing has been flashed thus far, this is just replacing the #3 position contents in the buffer). 12) Press Return to go back to the previous screen that shows the slot pairs. 13) The slot you changed shows the name of the file just loaded. This information will be stored into the info file, but you can change it to arbitrary name (up to 16 characters). To do so, press E, then type "Omnimon XL" and press Return. 14) It will as you about the BASIC in the slot. If you do not want to change its name, just press Return. 15) Repeat steps 9-14 if you want to change something else. Maybe you also want to insert Altirra BASIC into the same slot #3? 16) When you have everything you want loaded into the buffer, then press "F" (Flash All). 17) The program saves the info file then flashes *ALL* the buffer contents. It will reboot the computer afterwards. 18) At any time, use Escape to take you back, aborting whatever you were doing. Of course, do not try to abort while the program is actually flashing. Restoring factory defaults -------------------------- It is possible to restore the ROM's factory default state without reloading tiresomely the slot contents one by one. The procedure is this: 1) using the jumper (or switch), put the board into recovery mode, 2) power up the computer, 3) load the configuration tool, 4) press "F" to go to the flasher menu, 5) when the message "This ROM is protected. Accept it anyways?" appears, press "Y" to confirm, 6) let the program buffer the ROM contents, 7) select "Flash all", when the message "Toggle the switch..." etc. appears, put the board back into the flashing mode using the jumper (or switch). The program will then flash the flashable portion of the ROM with the buffer contents and reboot. Have fun, KMK/DLT Warszawa 19 X 2020

Let me ask, are you all talking about running the ATR8000 to use cp/m which most software expects 80-columns and then use it in a 40-column moveable window? Or some other software scheme? I understand that Atari 800 owners could've used the bit-3 to get hardware 80-column. But there is no source for that today, as far as I know. It's interesting to me...all the retro computing has put me right back into the 80-column angst that I also had back in the day. I wanted 80-columns and nothing has changed, lol....oh well, at least I have some 80-column on the VBXE card. I could also obtain a XEP80. But....I just wanted to clarify, is there any hope of getting hardware 80-column with this device? If not, understood, it's still a remarkable undertaking.

I think your point is well made. Karateka was one of the few computer games I purchased. Oh I was a fan of games, but mostly played games on the family's 2600. For my Atari (400, later 800xl, later 130xe), it was mostly about programming and later as a BBS system. But, I did want to demo the machine to friends, and had 3 or 4 games, one of them was Karateka. I was very pleased with the purchase, it was an 8-bit master piece. I never heard of the ST version until your post. I took a look at it on youtube. The person playing in the video was doing so defensively, throwing a lot of high kicks, rapid fire. It had the impact of being somewhat comical, who in real life would rapid fire, repetitively throw kicks into the air that don't land, plus the timing was so fast, it wasn't believable. You can fail to land a kick or punch in the 8-bit version too, but it never caused a suspension of disbelief. The timing of the game created more tension. The game was very cinematic, and felt ominous and foreboding. I get your point entirely, the impression of the ST version was that it certainly looks like an upgraded graphics version of Karateka, but something got lost.

p.s. if anyone has the original docs, that may set me in the right direction. I see that you can potentially set 8 rom sockets, but I don't see how you ever select the os rom that you want to boot from anywhere. Looks like the option key is broken on this machine, so that won't work for disabling basic. I have another keyboard but it has a massive metal shield, which won't work with the space available.. Bummer, anyway, if i get the directions it'll help me for later...thanks in advance.

Many years later....I have my antonia up and running. I think I may have reported a failed install last time I tried, I don't recall. But, the main issue beyond user error, is it didn't really fit in the 800xl case, there was some modding of the keyboard, getting a low profile socket to simultaneously raise it above one chip and carefully clipping the pins to get it just low enough to close the case. Having trouble finding a lot of docs on it though. I downloaded the ant17.zip form here. Thanks. I get into a configurator screen. I turned on 128K XE and linear ram. I found only one rom on drac030 called XLOS816.ROM, but all that does is say err 136 when I try to load it. Does anyone know where you get the images to use it in 816 mode? Thanks

Ah, look people have strong feelings on this, i get that. I wasn't trying to offer my own opinion on u1mb general reliability in a 1200xl, I only have my own experience and it always was with a rapidus, which we now know isn't a workable combination. I don't have any experience installing anything, of course. As a user, I go mostly to the most well known Atari technicians with decades of experience - like yourselves, I'm not saying they have more important views, not at all. I'm just saying like yourselves they have this tremendous wealth of experience, and so I seek out their opinions. I thought it might be valuable to share because what they told me was quite the surprise in some ways, but nevertheless, at this point I will say I've shared a third hand opinion, not my own. Objection sustained, I withdraw the comment. Of course, this isn't a survey of Atari dealers lol, I just have a borked Atari and have been pricing repairs....I can't wait to get it fixed. I do understand why people like the u1mb, I don't. But, for the right use case it's a well supported piece of kit.

Hey you all, I thought you might find this interesting, as you know from that link, I have an Atari 1200XL, with Rapidus, U1MB and VBXE, in fact I had two systems like that since 2016. Neither worked right. And, as it happens, I've written to various folks that do a lot of installs about this subject over the years, ...FJC, Lotharek, etc. Just so I don't confuse what they said, I'll quote FJC from his website: "Earlier this year, I was informed (by Lotharek) that the U1MB/Rapidus compatibility problems (which have blighted many installations for over four years) have been confirmed to be caused by the Rapidus accelerator itself." And, I was told by another vendor, they won't guarantee the install the Rapidus by itself, even in a 130XE. They'll try it. But if it doesn't work, then it won't be installed. That's without even the u1mb! And as for the u1mb in a 1200xl - even by itself that is hit and miss. All these Atari folks are super careful and ethical, I really appreciate that. Lotharek is very up front about Rapidus issues. FJC is a class act. I'm very impressed with the communication, but it is a pity about rapidus. Honestly, nobody has dinged the VBXE at all - or the combination of the two. It's basically been 1200XL doesn't always work with u1mb, and rapidus may not work anywhere and definitely don't put rapidus/u1mb in a 1200xl! doh!

as a person who recently faced this question (and not as a person with years of experience, because I don't have that)....here is how I ended up answering this question for myself. 1) program on a PC or Mac, because you can instantly compile your code and see results. You can easily manage art assets. It's just way faster than on the Atari. 2) Having examples means a lot. The two environments I found to be absolutely "swimming" in examples are Atari Basic and Assembler, that's because they were well documented back in the day, and people have posted literally thousands of examples on the internet which are easily found by google search. I find myself referencing De Re Atari all the time. So, this means, Assembler, since basic doesn't cut it. 3) I don't find assembly especially tedious, because what I use it for, is for the inherently tedious tasks anyway. By this I mean, for example, Display lists are just a list of bytes, C has a display list struct, but even if that looks like a clean implementation to a seasoned programmer, it doesn't help save time. Similarly, programming a VBI or DLI, may as well as do it in assembly, because you are basically filling hardware registers anyway....it isn't a task that somehow becomes easier in a high level language. But assembly for the entire program is tedious, and that's where a dab of C really helps. To toss out some pseudo code, I would organize in C with something like this: game_loop() { read_joystick() move_players() check_collisions() update_score() } and then each of the functions I probably called out to assembler, because lets say I need to update a score. Well the score is located in the screen memory at a very specific location of my choosing, using a characterset that may be custom. I"m not going to printf() the score. I'm just going to write the new correct, characters to the correct location. So what's the point in hoping a library knew how my game was written. Anyway, so that's what works for me....organize in C...mostly in assembler. Truth is I'm not as organized as some or I'd have probably fallen in love with MADS, but I'm too lazy to learn all that, haha

I am inspired by watching Linus Tech Tips, Flash Jazz Cat, and Retrograming news to do a blog type progress report. It's way harder than they make it look. But basically this is my discussing my compiler environment and trials coding a DLI. I just find it super interesting, especially in the Commodore scene all the reports on WIP. It's of "practice" quality, but anyway....enough intro, here it is.

Btw, I have now also removed the Sio2SD from the equation and have replaced it with an Atari 1050 drive, but it makes no difference. I made several other videos of the problem, but each time that I had hoped to reproduce the problem reliably, I couldn't, therefore I don't find the videos interesting any longer. I'm a professional programmer, that's my day job. I work in healthcare analytics. If I don't have the skills to operate an Atari, I accept my fate But in my view, I have a pretty good handle on writing code for the Atari in assembler,, although only tackling display list interrupts, reading from the joystick, antic operations, and stuff like that, obviously still to learn is XIO type commands and early startup - and I really will learn on as needed basis. As far as "understanding" why I have to hit multiple key combinations to switch the machine on and just launch a program from disk, I'm not going to understand it. It's also known as being stubborn. I don't wanna do it, I'm not gonna do it. Edit: p.s. this message isn't addressed to any person - I'm just venting. So, thanks again to everyone for looking into the state of things. I've kind of gone into this troubleshooting mode since yesterday...and now I'm trying hard to reset the human here, and go into another mode - gotta get back to coding, lol

OK, what this video is about is showing a short sequence of events that results in a problem. I titled it "Cold Boot to Basic", but where this u1mb initiated reboot is considered "cold" or not, I don't know. My issues begain with desiring to use "classic" with fujinet. FujiNet has a program where you set an ATR - and Fujinet reboots the machine - that results in problems. So, it isn't merely when I touch the reset key, but other restarts. As far as I know - which is very little, hitting the reset button on the machine pulls the /reset line on the CPU. I still don't understand how this setup can have the wrong CPU and yet successfully pull the /reset line. Anyway, I'm backing up now, not going down the path of workarounds, but now, just trying to be more specific here. If you have a cartridge in the port, it shouldn't boot to basic. I don't want to workaround that, just pinpoint where the problem occurs. In this video, I power off many times - the CPU is wrong as listed in U1MB, both the speed and cpu type. Powering off doesn't correct that problem, it is pretty much wrong 95% of the time. Occasionally it looks correct, but I haven't figured out how to regenerate a correct result. One thing I'm trying to add here, is I don't necessarily have to have a problem from recently touching the reset key on the Atari, I seem to be able to get a problem when what appears to me what is happening is a software initiated reboot. If that is explainable - I don't know. I am going to pull the U1MB from this system. Even if it isn't the problem, it is what is delivering up a host of OS's and Basics internal to the machine, and I never wanted that - at all, so that will be one improvement by pulling it. And secondly, it just simplifies this troubleshooting process to have it removed, imho. So any hardware gurus that want the job, pm me.

I think so. But, here is a video, showing it not working quite as expected to me. I wanted to catch it. Like I turned on the video camera the first time, and it showed Altirra OS - I was like, c'mon! I didn't choose that, but I also didn't capture the change on video, so I ultimately did find one glitch that seems to occur quite often, which is the processor in system information. and then not loading from cart is fairly common. p.s. Also I tried in DOS hitting B run cartridge, and the message was no cartridge. But when I go into Rapidus, and set it back to 65C816, and reset u1mb to defaults, I can then reboot the machine, it loads SDX, I type CAR, the cartridge loads, because that always works. I can turn SDX off, and the cartridge loads, that always works. It seems like wild crazy stuff, until I set it back to the mode that has worked these past 4 years, and that continues to work, just as it always has. anyway, could be I've explored it as far as I can.

On the first part, gotcha, I mistook a word you had used to mean something else - we are clear now. on the second part - no way. Uh huh. I understand it must seem that way, but I am not accidentally choosing anything. If I am so hopeless incompetent as to be accidentally choosing random OS's all the time, within the space of minutes, while I am very carefully and intentionally not doing that - then I don't need a machine with a bunch of OS installed. But it isn't me - I'm not doing it.

I'm officially done. Tried this, and first of all the cartridge only loaded part of the time, and then "MEMO PAD" starts coming out. And the Rapidus wont' enter it's BIOS screen. "MEMO PAD", huh? I thought that was an Atari 400/800 thing. I reset the u1mb to defaults, and Rapidus now enters its BIOS screen again. The funny thing is, the machine is *stable* when it comes to accelerated mode, it's just I developed this desire to work in classic mode, which is like hitting my head against a brick wall. It's kind of funny how it randomly glitches into Atari history here. What next, will it force a game of pong? haha...omg...well, I gotta take a break from this, later folks