Shawn Jefferson

Hi, I'm on a quest to get the PAL chips I need to complete my 1450XL build, and I noticed a few interesting things and also had some questions. I thought I'd create a new thread rather than pollute the 1450 build thread further. First of all, the equations that are located here, seem to have some errors. http://www.atarimuseum.com/archives/pdf/computers/8bits/1400-PAL_Chips-and-Equations.PDF I have a PAL B (CO61917) that I ordered from Best Electronics, and was able to test it, and I noticed that VOTRAX LTCH and VOTRAX STB seem to be mixed up in the pinout in that PDF. If you look at the speech handler document, it says that the latch is at $D104 and strobe is at $D100 (opposite of the equation document). I also believe that the PAL A equations are slightly wrong (there's edits in pen on the document here and there too), but I believe that RAMINH should be set active LOW, and the equation does not show that correctly. Also, it looks like the 1400XL PAL A is very similar to the XL/XE MMU CO61618, albeit with different pinouts. Equations are very similar though. I used PALASM to create a JEDEC file for PAL A, since no file has been posted by anyone else as far as I know. I haven't had it programmed yet though, so haven't been able to verify it's correct (or that the equations are correct, but they seem fairly straight forward knowing that they are very similar to CO61618). I did have PAL C programmed, but it appears it was not done correctly, as changing the inputs does not do anything with the outputs as it should (they all stay HIGH always, even just setting EXTSEL low, which should make PBIDEN low if I understand right, which makes me think it was not programmed correctly, or at all). I will have to try to get those programmed again. As far as testing, I built an Arduino IC tester (this one: https://github.com/akshaybaweja/Smart-IC-Tester), and also added the Arduino DRAM tester (https://atariage.com/forums/topic/289391-dramarduino-dram-tester-with-arduino/) to it (4164, 41256, 4416, and 4464), as well as added the capability to test some of these PALs, such as the CO61618 (tested several I have successfully), and the 1400XL PAL B and C. My PAL B passes fine with the pin transcription error mentioned above. On that note, does anyone have the equations for the 1200XL MMU PAL, CO60609? And of course, if anyone can dump their working PAL A, that would be beneficial, although I do have (untested) equations and JEDEC file I created. I attached those files here, but take as-is, untested. 1400XL-PAL-A.zip

This chip is the CO60609 (1200XL MMU) I found out. The writing is very small and blurred, so hard to tell, but I have verified that now. It's definitely not the PAL A chip that I need. I have been doing some research into these PAL chips, and working on getting them built from the equations. I will start a new thread for that, as there's a few interesting things there. I still need PAL A, and now I've discovered that I also need PAL C made properly, as the one I had programmed doesn't seem to be correct. I was able to verify my PAL B is correct though.

The MIO has been relisted: https://www.ebay.ca/itm/154358763578

Well it looks like the winning bidder on my auction has flaked out, completely ghosted, no responses after multiple attempts to contact them. I am just in the process of the Unpaid Item resolution with eBay, but I suspect this guy is a dishonest bidder and I will end up re-listing the item at some point very soon. Just so everyone is aware not to trust, trade with, or at least be very wary of this person bidding on your items: Ebay username: dentist2002 Name: Jordan V Anderson

Yes, I needed that one as well (U11), and had someone burn that to a PAL chip for me already.

I wonder... as these boards are the 1450 boards that were created later on. Hopefully this is the correct equations, and I guess I'll have to try and figure out how to program a chip with these then. Hoping someone with a working 1450 board may dump the chip for me, as at least we know that it will be correct in that case!

I took a picture and attached it here. I was hoping someone who has a working one could dump it, especially if the files don't exist somewhere on-line already. Looking over at Atari Museum, is this the chip description: http://www.atarimuseum.com/computers/8bits/xl/1450xld/1450XLD_GATE_ARRAY-BARBARA.pdf

Hi All, I finally got back to this project that was almost done, and got the handler EPROM and the PAL 'C' chip burned and populated (the last chips I needed) and built a power supply from an old PC ATX power supply. However, turned it on with great trepidation... and got just a black screen. I am getting the correct voltages on the motherboard I believe. What I suspect, and pretty much expected, is that I don't think I have the correct PAL 'A' chip. I ordered this from Best Electronics years and years ago, I don't think I was actually sent the correct part. It's a PAL16L8, but does not have the C061919 label, it's labeled with C080509 or C080609, its very hard to read as it's quite small and not very clear. Can anyone send me the JEDEC file for the PAL 'A' U12 chip from their 1450XL? Hopefully that will be all the issue is for this board. *fingers crossed*

This MIO for sale on eBay is one of mine. I have two of them, and really don't need two. I've offered stuff for sale through Atari Age directly in the past, and that has turned out well for me, but with the MIO, I really don't know what it's worth so wasn't sure what to ask for. I figured I'd let the free market decide and posted it up on eBay. I remember these over-heating back in the day, and many folks that I saw running them took the end plates off entirely, and setup fans blowing over everything as was mentioned. I was always impressed with the MIO and the RAMdisk capability was great with the 1MB version, as well as the ability to run faster modems than the SIO modems available from Atari. Of course we all wanted the CSS Blackbox, but I don't believe I ever even saw one of those BITD. Maybe one (?), but I didn't get to play with it personally.

Hi, Selling one of my 1MB ICD MIOs on eBay. Just slimming down the collection a little. https://www.ebay.ca/itm/154335357869

I would really love to see games ported to my most beloved platforms, like the Atari Lynx (and Atari 8-bit computers), but generally I can understand why programmers aren't jumping up to do these ports. You have to really, really like a game to spend the time to port it to another platform, especially without source code. It's probably better to write a game based on a similar idea, so you won't have to deal with all the people that will tell you all the things you did wrong in porting it, how it doesn't play 100% like the original, look as good, control as well, etc. The lynx, while having great graphics hardware, has some crippling drawbacks: the small screen, and the cartridge system, which makes it fun but also frustrating to code for. So you also have to love the platform you're porting to as well. Whenever it does get done, and done well, like the Space Harrier port to the Atari 8-bit, I'm amazed and happy to see it.

Your code also becomes non-reentrant, which means that you have to be very careful with leaf functions. I suppose that would have to be a somewhat complex program though (??), but still, that may be a nasty surprise if you aren't ready for it. On the Moria port, I had to be careful of that when I was moving local variables from the stack into zeropage. I believe I did find a few examples where I couldn't move the variables easily off the stack. Using the register keyword avoids the problem I mentioned above, but there are only 6 bytes available (I shouldn't have said 6 register variables, since an int will use up two byes. And the code to push and pull them off the stack that allows your functions to be reentrant. A good compromise solution for some extra speed without changing the program much. I thought posting a reply would be good for anyone who's looking at CC65 for programming, and add to the points you made in your document. I didn't think you'd needed the advice, you've been using the suite for a long time now! I've been away from it for a while now, but I do have a more recent version I should upload that has some bugfixes and more polishing. There's still a bit left to do, to truly call it done. They are an interesting game genre, and I played them a lot through high school and at jobs where I had only had a monochrome PC at work.

Very nice article @ilmenit! That should be very helpful for people who are programming in cc65. I wasn't sure if you mentioned __fastcall__, but that may be a default behaviour of cc65 now. I find that if you are used to the way that cc65 does things, you learn to program in the "cc65" way. Generating assembly listings and map files when you compile is mandatory, and you should get in the habit of looking at them to figure out what cc65 is doing both from a code generation point of view, but also memory usage (in larger projects). In larger projects I don't see how you can really use static locals (you'll run out of memory), but maybe there would be some cases where that might work. When I was porting Moria to the Atari 8-bit, mostly I started optimizing in this order: 1. Making sure all the data types were the smallest possible (unsigned char instead of int). 2. Using the register keyword to have some local variables in zeropage (cc65 only has 6 zeropage "register" variables), and there is a little overhead to save and restore the contents. Usually loop variables and pointers are good candidates. 3. Any large local variables, were changed into globals. Some of those could be shared (if very careful), like buffer string space. 4. Moved heavily used globals to zeropage, both to optimize memory and speed. 5. Lookup tables, for speed mainly. 6. With Moria, I needed space and would often be trying to eke out bytes to get things to fix in cartridge banks. Including making sure that read-only data was stored in the cartridge bank and not in the main memory RODATA bank. Memory management is a huge thing with a small 64k machine.

I ported Moria v5.5 to the Atari (using the VBXE2 for the 80 column mode), which is likely a similar problem to Rogue. One of the big things you will have to deal with is the 40-column screen. Most of these rogue-likes were written for an 80-column screen and you will face a lot of issues porting to a 40-column screen. Another thing is the memory use. In Moria I am doing A LOT of cartridge banking, as well as VBXE banking. The map itself is around 24k in Moria, and is dynamically created each time you enter a level. There's one function in Moria that had to be split across two cartridge banks even. The game was just not designed for small memory footprint computers. I've started working on a 40-column port of Moria, but the game is going to have to be changed quite a bit, even to the extent that the names of the items will have to change as some of them are much longer than 40 characters and just won't fit on the screen even. I got a bit disillusioned with that though and basically stopped, but I may pick it up again someday.

Time Pilot 46,000 The controls take a bit of getting used to, that's for sure! Never played it in the arcade, neat game.

Hi Karri, LOWCODE is used on quite a few targets that have banking windows, like the Atari 8-bit. It just ensures that code that needs to be "low" in memory, is in fact in low memory. The Atari 8-bit has standard banking windows at $4000, $9000 and $A000. I believe that IRQ code in the library would be in LOWCODE so hopefully it doesn't get banked out during an interrupt. On the Lynx it isn't really required since there's no concept of memory banks, but this became standard in cc65 since quite a few of the targets have the same issue. I'm not entirely sure when that happened. You could just change that to "CODE" on the lynx if that's an issue.

I doubt they have the rights to this game as well.

Does cc65 still use environment variables to locate the lib and include dirs?

Karri, with what you know about the Lynx, do you think it's possible? I guess you'd have to load data in an interrupt, and then you'd have to deal with the block/offset issue. For an 8-way scrolling game that is going to be pretty ugly... there's probably no good way to organize the data for faster loading. I haven't actually looked at the SDcard API, so maybe it would be possible, and practical... I guess someone will have to do it to prove it can be done. One thing that probably would be possible and quite interesting, is to release a game that could load levels from SD card, so that users can create their own levels and just put them on SDcard along with the ROM of the original game. Or an RPG with additional maps/quests, etc...

I looks like he is just counting up to 75 in _playtime, and when that reaches 75, he increments _playtime+1, and when that rolls over to zero, he increments _playtime+2. That's a pretty common method of time keeping, used in the Atari 8-bit computer OS too. You then just have to grab the value of _playtime in your mainline code, and then grab it again, subtract the values and do some division to get elapsed time. It's easier if the VBI is running at 60hz.

I think it opens up some possibilities for games to have very large maps or more levels, but not much else unfortunately. On the Lynx everything has to fit inside the 64k, and you can't use the trick of bank-switching the cartridge into a large memory space (8k/16k) like on other consoles or computers. Loading stuff from the Lynx cartridge is also not very fast-it's not random access. It acts much like a tape drive (the original design I believe), and you actually have to "seek" to the location in the block that you want to load into memory, by reading the values from cartridge and discarding them. It's one of the (beloved/hated?) limitations of the Lynx.

It's not possible for anything on the cartridge to do DMA to the lynx RAM, the "cartridge" is presented in memory as one byte and is not memory mapped like on other systems. What's possible on other systems is not possible on the Lynx for this reason. It's great that you have these ideas, but you should read up on the hardware design to ground them in some reality as well. That taxi demo isn't "streaming" the video from the cartridge, since that is really impossible (from what I know about the hardware... someone could correct me if I'm wrong and explain how that would work.) Yea, it would be cool, but we're stuck with a legacy from when the Lynx designers wanted to put a tape drive in Handy. (dumb)

Now you are really talking about a program with only two users... Nice work on the zx emulation, makes me wish I had to rapidus.

This sounds like "sector skew", which I believe some of the 1050 enhancements could also do, but mostly it wasn't used much from what I remember, since while it could speed up disk operations on one type of drive, another might end up being slower. Once we all had Happy drives, we were reading a track at a time anyway.