RevEng

Yes. The game logic is only loosely coupled to the frame rate, so unlike a lot of games, it runs pretty much as fast under PAL as it does under NTSC. The music tempo is also identical under both PAL and NTSC. Soon

Sorry, I don't see it, so no, we're not all agreeing it was in poor taste. Linking to someone's profile doesn't equate to promotion or glorification. You're making that leap, but there was no endorsement in the text before or after the link. Being in list itself isn't an endorsement either. To me the fact that the linked profile says "banned" right under his name makes the link a cautionary tale of how badly one can f*ck up. But I'm bringing that interpretation in myself. James wasn't sending that message either. Sometimes a link is just a link.

I'd rather the list be accurate. ZPH wasn't around at that time, but I'd say the same for the extreme example of 2600 Pigs In the Castle. Sometimes truth is ugly.

Sure, all of that. Nothing is free, and the 320 modes use most of the same circuitry as the 160 modes. To upgrade the 320 modes with more colours, you'd need to upgrade that common circuitry, at which point you might as well enhance the 160 modes too. Then decades later someone would ask why the 320 modes only have 12 colours, when the 160 modes have 48.

Ah. The current version of 7800header doesn't do that, so you can avoid that with an update. Historically that header bit was a ram modifier for the supergame format, hence the name, so 7800header would auto-add supergame if you chose supergameram. After some of the header thread discussions, we moved over to it being ram@4000 or EXRAM, instead of being a supergame modifier. At that point I updated the 7800header behaviour, and renamed the option to "ram@4000". (though the alias "supergameram" still works.) [edit] come to think about it, the previous 7800header behaviour probably was the cause of Karl's 32k+ram test working too. He likely got the unintended 32k supergame hack.

The header has supergame flagged, so it's being interpreted as a shortened two-bank supergame. This works with a7800, and is a work-around for this particular issue, but I'd expect some devices might have problems with it.

Wow, that's super impressive! This approach would also correct edge-case display issues that some TIAs exhibit.

Some preamble... There were a lot of aspects of the a78 header that were left undefined for years, and while we've tamed some of them, some inconsistencies remain. The supergame ram bit (bit 2, aka EXRAM) isn't a base for the banked ram bit (bit 5 aka EXRAM/X2), so 7800basic is doing the expected thing here. You don't add on a banked ram device to a ram device in a cart, rather it's an entirely different sort of implementation. That's the thinking, anyway. Having two different romsizes will lead to unexpected issues, since compile time flags are being set for both formats. I've just added code to my local repo so 7800basic will error out if a second "set romsize" is encountered. Regarding 32k+ram being non-functional in a7800... The emulator only presently implements mappers that had finished game roms published that are using those mappers, instead of just allowing a mix-and-match of features. The emulator was forked from Mame, so this link to physical implementations makes sense in that context. I'm looking to lift this somewhat in some future release, and 32k+ram should be part of that. But it requires a big overhaul of the header parsing, and the way the emulator manages the bootstrapping of those hardware features in separate object classes. In the meantime, using 128k+ram and not bankswitching for testing doesn't have any downsides IMO, except maybe wasting a handful of rom bytes for the bankswitch code.

Characters in 7800basic are limited to zone Y alignment, due to DMA concerns, so that may or may not be a problem here. RAM based sprites are possible, but it's a fair bit of under the hood work. The plotsprite command expects a bunch of constants named after the sprite, which are created by the incgraphic command for that sprite. If you can provide an alternative set of those constants (you can dig them out of the *.symbol.txt file) for the RAM location, then plotsprite will work equally with the alternate ram-based name. Of course, you'll also need to copy the sprite into RAM in the weird format the 7800 expects, with a page of RAM separating each line of the sprite. At some point I'm going to try and come up with a pseudo "incgraphic" type command that sets up the symbols for you, for ram based sprites, but I'm a ways off from implementing that.

I'm developing under Linux Mint 20.3, which is based on Ubuntu 22.04. I don't have the issue... based on a bit of googling, I think it's likely aggressive power management turning off your audio device, and then turning it back on when it's needed. (the fade-in) Try out the fix from the top reply in this thread.

The chip in the schematic is an FT232R, and the schematic is for a stand-alone USB->AtariVox adapter that Richard H created and provided to some developers a long while back. The AtariVox doesn't have the FT232R built into it. A quick an dirty adapter can be built with a $5 TTL USB to Serial 5V adapter and a serial db-9 connector.

Your question isn't entirely clear. If by "the chip" you mean the speakjet, and by "wire a USB" you mean a plain old USB cable, then the answer is no. Despite being "Universal Serial Bus", USB doesn't communicate like a legacy serial bus does, which is what you need here. (with non-legacy TTL voltage levels)

In the absence of more info... Try changing your network cable and connect to another switch/AP port. If you can't swap the cable, maybe switch your network adapter settings from auto-negotiation to explicit speed and duplex. The only vague theories I can come up with to fit the facts - asymmetric affect on up/down, two different nics encountering the issue, and a network adapter restart fixing it - involve some kind of occasional negotiation related failure, and the nic restart bounces the port and starts the auto-negotiation process over. Perhaps one of the wires in the TX pair is marginal, or a switch port is dying. It might be helpful to run "netstat -s" before and after an issue, to see if any of the counts have unexpectedly gone up. Also try to observe the activity LEDs on the nic port and the switch port during the event. If the issue happens outside of a live stream and you're done collecting observations, see if merely unplugging+repugging the network cable from the PC fixes the issue.

I appreciate that! I'm pretty keen on getting RMT incorporated too. It's in there on the backend already, since I added it during the petscii robots development, but I need to create some 7800basic commands to make things easier. A few notes, since you're already looking into RMT authoring... The 7800basic driver is based on Eckhard Stolberg's RMT assembly port to the 7800, which was RMT v1.20. It's best to stick to that version of the authoring software, as I'm not entirely sure what driver changes later versions require. This may change in the future, based on how A8 RMT developments with LZSS pokey data streaming shakes out. Instrument speed should be 1x, since 7800basic only calls the driver once per frame. I pulled and converted all of the RMT music from the asma archive, and 1x seems to be pretty standard. Compose with one pokey. This may change later.

Step aside, guys. Goalposts are moving. Trivial in a technical sense. The point of a proof of concept is to prove out the tech, not to write a fully featured game. I linked a definition of proof of concept earlier, that you really should have a look at. The demo uses 12 colors from one palette set for the tiles, and another 12 colors from the other palette set for the hero. The enemy sprites can use either of those sets of 12 at any time. With a bit of planning that's barely a hindrance, let alone some intractable problem that can only be proven by a fully fleshed-out game. Again, trivial in a technical sense. If there's dma and cpu available, these things can be done in the conventional way. Look around and you'll see the 7800 has games with collision detection and game logic. This isn't the big technical hurdle you seem to think it is. I understand. It will never be a proof of concept, because you'll keep shifting the requirement of what a proof must contain. Just like there is No True Scotsman, eh?

Collision detection is trivial, as are additional sprites. There's plenty of DMA and CPU time left here, so this could be added just like any old 7800 game. I'd disagree that the demo *needs* those trivial things fully fleshed out to be a proof of concept. A proof of concept isn't the same thing as a fully featured game engine. It's been used masterfully here to suggest angular lines on Link's ears, and give some shadow under his chin. There's purpose, it's just that you prefer blockier looking graphics. Everybody has their own taste, I guess.

Maybe a picture will help. Here's the top and mid section of your ship graphic. I've fractured the sprites vertically so you can better see how things are split up... When your sprite (tallsprite or otherwise) isn't zone aligned, two sprites are required for maria to draw it spanning the 2 zones. In the above picture, the top of your tall sprite gets split across zone 1 and zone 2. The mid section of your tall sprite gets split across zone 2 and zone 3. The bottom section of your tall sprite (not pictured) gets split across zone 3 and 4. If you plot your tallsprite 8 times across the width of the screen, it means that zone 1=8 sprites, zone 2=16 sprites, zone 3=16 sprites, and zone 4=8 sprites.

The compile always tells you how many objects per DL you get... The thing you need to keep in mind is when you plot a sprite to a Y coordinate that isn't a multiple of the zoneheight, it creates two sprites; one to draw the top portion of the sprite in the upper zone, and another to draw the bottom portion of the sprite in the lower zone.

I'm just now catching this on youtube. Great interview overall, and my ears especially pricked up when you talked about 2600 magazine. In the pre-internet days I was a pretty regular 2600 reader, and much later in 2006 I had an article published; it went through the analysis and steps to get root on a particular consumer NAS box. (I got a 2600 magazine hoodie out of it.) So fun to hear I'm not alone with the dual-2600 personal history!

NVMEs drives do run hot, but that's for sure on the overly hot side. Does it have a heatsink? Are the two drives located in areas with similar air flow and/or is one near another component trying to shed heat? (e.g. cpu, gpu, vrm)

You're welcome! I know from personal experience it's super easy to get turned around the wrong way between the png indexes and the 7800 indexes.

From the first posted script, try the values in the comments instead. Bracketed values show the link to the 7800 bit ordering... def map160B(val): ''' 3276 1054 ''' ret = 0 if (val & 1) == 1: ret = ret | 4 # 64 (6) if (val & 2) == 2: ret = ret | 8 #128 (7) if (val & 4) == 4: ret = ret | 64 # 4 (2) if (val & 8) == 8: ret = ret | 128 # 8 (3) if (val & 16) == 16: ret = ret | 1 # 16 (4) if (val & 32) == 32: ret = ret | 2 # 32 (5) if (val & 64) == 64: ret = ret | 16 # 1 (0) if (val & 128) == 128: ret = ret | 32 # 2 (1) return ret Transparent color indexes are at 0,4,8,12, so you'd need to skip those in your mapping.

It can go taller too. The graphic source image, pre-scale, is 144x144.

Despite spending my fair share of time playing the A8 version back in the day, not really. It was your raising it here that just got me thinking about the board, and how the 7800 might be able to amp things up a bit.

Just throwing this out there... you can make a pretty nice isometric Archon board out of a reasonable number of 160A characters...