Jump to content

Chilly Willy

Members
  • Content Count

    842
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Chilly Willy

  1. The problem with the MD pad is that other than up and down, all the other lines are being actively driven by a TTL chip that is being powered through a potentiometer line pulled high on the Atari with a fairly high resistance. It's amazing the chip works at all, but that's TTL for you.
  2. Yeah. It needs a pull-up resistor of 270 to 660 ohms between pin 9 and 7. The only thing you can say is that there are no active parts trying to draw power from a pot line, and that the dpad and first trigger are properly connected for an Atari. So it can work as a one button pad, but needs the pull-up resistor for the second button (which connects to pot A).
  3. Funny - that POTGO register isn't in my Altirra Hardware Manual pdf... very strange, and I didn't even think about the fact that it was missing. Need to find a different copy of the pdf if the one I have has such a basic mistake in it. And that idea of putting using a FIFO for the serial is nice for high baud rates. It's something a number of old systems needed, like the Amiga. Even for not-so-high baud rates - DMA contention on the Amiga meant that you could lose data over MIDI because there's no FIFO for serial data. Anywho, probably a better idea for compatibility with existing software would be to make the first POKEY respond to $D200-F, a second one to respond to $D210-F, and any others to be bank selected to $D220-F with the bank select at $D23x... or something akin to that.
  4. That first org is $2000... which is a bit low for a cart. Try $A000 for a 8K cart, or $8000 for a 16K cart.
  5. Yeah, that's one of the easiest (to program and to see) way to get feedback from a console on a WIP. I do that on the Genesis all the time... I usually change the background color since there's always a lot of that on any screen. I usually set a different color at different places in the code, so just a glance at the color tells you the last thing that got done.
  6. https://atariwiki.org/wiki/Wiki.jsp?page=Atari BASIC Atari Basic Rev. A.rom ; ? PEEK(43234) should return: 162 Atari Basic Rev. B.rom ; ? PEEK(43234) should return: 96 Atari Basic Rev. C.rom ; ? PEEK(43234) should return: 234 If you want to identify other Basic carts, you'd need to check each one out. Start on this page https://atariwiki.org/wiki/Wiki.jsp?page=Basic
  7. There were all kinds of weird boards for the 400/800. There's a doc on Atari Memory Expansion boards that covers many of them, along with expansions for XLs and XEs. I had the Mosaic memory expansion. It gives you 48KB of ram like normal, then a number of 4KB banks of ram at $C000-$CFFF. You set the bank by writing any value to $FFC0+n, where n is the bank number (max of 36 banks, or a total of 192KB including the first 48KB). I made a number of patched roms to utilize Mosaic bank ram for things like BASICXL and ACTION! so that I could run them from DOS. Left me 4KB more ram for programs, too.
  8. Yeah, $D20B and C are unused, and that would make the logic decoding the bank register slightly less complex. You wouldn't need to decode for $D2xx since the POKEY chip select would handle that. You'd only need to look for B or C, and C is probably easier of the two.
  9. Not aware of any others, but Altirra works great in WINE. That's the emu I use in Xubuntu (the repo version of A800 is only 3.1.0).
  10. Well, just as an example, you could simply make all POKEYs respond to $D200-$D20F, and writing a byte to $D2FF would set a latch that selected one of 256 POKEYs. That would be super-easy, and also super-silly.
  11. Yeah, sounds like you got old stock. Bummer. I later bought some 256Kx1 DRAM that I planned to use in modifying my Mosaic card with, but then got an Amiga and moved away from the various Atari plans I had at the time. Still got those DRAM.
  12. The PIA can interrupt the CPU on either the positive or negative edge of transitions on both those lines. They're part of the PACTL and PBCTL register settings - see the Altirra Hardware Manual (10.5).
  13. One more change... I was thinking about how to minimize the amount of soldering needed, and where to put the board. Under the ANTIC or CPU seems like the common choice for memory and video cards like this. I'd still need to solder lines for all the PORTB signals... or would I... If you're sitting under the ANTIC or CPU, you have all the lines, so just decode PORTB yourself. More parts... less soldering... it's a trade-off. So for another 74LS21, another 74LS00, and a 74LS374, you don't have to solder any lines to the PIA. The cost is negligible, so it's totally worth it. 😎 Yes, it also latches the direction bits, but that's no big deal. The direction bits get set once to $FF, and from then on you just store the PORTB bits. I don't see it being an issue. With this addition, the only line to solder is the /EXTSEL. I can see how XL ram boards worked in the expansion port on the back. This could also work for XEs with ECI... which I don't have on either of my 65XEs. Well, I do have my brother's old 800XL if I wanted to make a fully external version.
  14. Weird - my Mosaic 64K board uses eight 4164 chips. The 32K board (from Atari that I got originally with my A400) used more chips. I'd guess yours is an earlier model before the price on the 4164 dropped enough to make it usable.
  15. Yes, which is why people wonder about how much editing they did... was it really necessary, or just them being a bit overly cautious about memory usage? If they had more time, maybe they'd have worked more of the original graphics back in.
  16. Given the sheer number of 2D games on the Playstation, something tells me there was more to that than just a "Sony anti-2D stance". Sounds more like an excuse than anything else.
  17. The maps themselves aren't the issue; they're tiny (relatively speaking). What takes all the space in Doom is mainly the sprites, then the wall textures. That's partly why Doom on consoles featured edited levels: they removed a bunch of textures and sprites to fit smaller carts. They could have easily given you dozens of levels... if they took the time to edit the levels to only use the textures and sprites that fit.
  18. You might look at formant speech synthesis. That's probably the closest to what AMY is doing here. You can use it for voices and melodic instruments pretty easy. The noise sources are for more fricative sounds.
  19. Sony didn't have an anti-2D stance, that was Nintendo. Sony had tons of 2D game through its entire life, while the N64 had almost none, and nearly all the ones they had were 3D with a fixed camera on the side.
  20. So is that really a bug in rmac, or in the sound code? Should the labels have been SET rather than EQUed? I could see the author of both arguing the other is wrong.
  21. Pretty cool. I love seeing all the different things people have come up with. I like that idea of using a SIMM for the memory. That was a great way to get a lot of DRAM for relatively less at the time. Anywho, for the /EXTSEL line on my design, run the CE2 signal to the base of a typical NPN transistor. The 65XE would need the /EXTSEL pin on FREDDIE lifted (it's tied straight to 5V in the schematic), and soldered to the /EXTSEL from the expansion, along with a 3K ohm pull-up resistor. 800XL and 130XE systems already have the line pulled high with a 3K ohm resistor, so you would just solder line to it directly on those systems. Need to check the schematics for a 600XL, but I'd guess it's like the 65XE - just pulled straight to 5V. Just checked... the 600XL schematics I found shows /EXTSEL connected to the expansion port and pulled high like it should... the 600XL has PBI? I did not know that...
  22. Looking at schematics for the XL, 65XE, and 130XE, it seems the way to deal with internal RAM is to use an open collector driver to assert /EXTSEL on all models when the expansion memory is selected... that would be driven off the CE2 signal in my schematic.
  23. Yeah, it's kinda the reverse of my idea - latching the other usage and then PORTB is just a bank, while my idea is latch the bank, then PORTB stays the normal function. Seems more compatible to me.
  24. Oh, I read that as a hex constant, not 0-whatever-11-whatever-0. 😁 It would hold the latch clear, but otherwise act normally. So the self-test would find four banks of ram like the 130XE. Without using PB6 to latch the bits, it should be completely 130XE software compatible. EDIT: I do see an issue on an XL - when the CPU or ANTIC accesses bank ram, it should disable onboard ram. The XE mapper does this, but the XL wouldn't. So the design above isn't XL compatible yet. I need to check into the easiest way to do that on an XL. I do have a couple 800XLs to go with my two 65XEs...
  25. Nothing. You just switch the OS ROM to ram as usual. Unless you mess with PB6 and 7, it acts just like a normal 130XE would. And I already changed the title to 4MB... damn shift key. 😁
×
×
  • Create New...