R0ger

But the background is moving ? One of them has to be redrawn.

How does it work ? I can see the cars are combination of PMG and field graphics, so it must be some kind of soft sprites. But it's too fast for that ?

So do you want people with U1MB to run the game or not ?

Hmm .. I've never actually seen Sanwa original. I use some copy, I think it's Zippy. And that uses the force limiting levers. I've seen this solution on some other copies as well. I can see how this direct method will result in much tighter dead zone.

If you handle collision in VBI, you should also handle the movement in VBI. You should do it at the same time. It makes absolutely no sense to solve movement 'anytime' and collisions only in VBI. It does however explain why it behaves like you describe it.

Problem with these is that sometimes the diagonal directions don't work properly. You basically limit both switches to about 70% deflection. That might not be enough to trigger them both. It can be tuned by carefully bending the switch lever, but It's much easier with square limiter plate, as the dead zone will be also square. Even with those some tuning is useful, I usually want the dead zone to by symmetrical and same for all the switches and directions.

Basically it's 1 cycle per byte, and 2 cycles on badline. Same for PMG, it's 5 bytes per row, so 5 cycles per row. And of course, if 32 is enough for you, just do it.

Nice, but too big. And doesn't work on NTSC, and doesn't work on most s-video inputs.

Oh it's emkay who is badmouthing you ? Well in that case you can simply ignore it. On the other hand, using CC65 ? Why ?

Well that's the issue with early reports. Problem is, 90% of all projects really do end up unfinished. Say this will be one of them is indeed disrespectful. Saying it's not one of them is on the other hand quite optimistic. There is tons of issues ahead of you. When some someone doubts about my projects, I certainly understand, where it's coming from 🙂 But it's certainly not a hoax, I'm sure, at the moment, you honestly believe it can and will be done. So just keep working, and silence the naysayers by releasing it 🙂

Well certainly Atari has very iconic logo, and so does Commodore. I think mascots are simply Japanese thing.

Atari doesn't need iconic character, we already have iconic computer 😁

Wow, that's lot better then I expected .. none of the frames is really pretty, but it looks great while moving.

Textmode is imho a must for game like this. When it's already designed like that, it's most of the work done. 1024 chars is no issue, as long as they are not on the screen at the same time, on the same line. Game like this does not need to refresh every frame, so there is plenty time. The character is rather well done and small though, I wonder if it could be done in half resolution. That's where the Spectrum version is easier.

It certainly wouldn't be easy to convert all the graphics to 160. It would get more of that Atari feel though. I also think that using Spectrum graphics as is would be the best. The color isn't that important in this game anyway.

There are some phonemes which are not in Czech. I wouldn't say 'way more'. But the system I should be flexible enough to add them. And I plan to support English, it's just not very high on the list. Automatic intonation and accents are much more complex issues, compared to phonemes, but it's no problem with your kind of use, as you can define that manually, to your liking.

I'm actually working on brand new speech synth. It uses slightly different approach than Sam, and it can run with screen on - that's one of the reasons I'm doing it. It's quite in the beginning though. And it's not aimed primarily at English, even though some kind of English would be possible for sure. I have some first Atari code working, and while it's really hard to understand so far, I think it looks promising. I plan to release something with it in March. By then I should know lot more, and I will not demonstrate anything before that.

Ok, let me rephrase the question .. you say: "I use hardware repetitive registers" .. but .. why ? Where is advantage in that ? You want d301, why not simply use .. d301 ?

Well with PDF it's more of a historic issue. It started simple. It didn't last simple. Anyway I can't come up with any format less suitable for A8 right now

What is the point of using mirrored addresses for hardware registers though ?

I'm not familiar with the game, so I don't know if there is scrolling and if how much, how fast it is, how precise the collision has to be .. that all will affect what method is best.

You just compute collision with a line .. or create table where for every X coordinate you have a height of the terrain. There's like hundreds of way of doing it.

I'm doing little something with digital playback, and I decided to finally try this trick by myself. It seems to work nicely in current Altirra, I use values 3,5 or 1,3. But what is the consensus about the real hardware ? Is it reliable enough among all the machines ? Is there some new development ? I don't remember seeing anything new in this are for like a year.

Well on Windows Altirra launches basically instantly. And if you can set it up so it won't launch another instance, and just reload the XEX if you run it again, which will even keep breakpoints and all. Can't comment on Linux use though. On Windows, I don't see single reason for Atari 800.

Also it's not just about what to change, but also when to do it. VBI is always the safest place. I'm not familiar with Atari 800, but debugging on Altirra has some really cool tools for stuff like this. First it does show the screen how it is currently displayed, with all changes delayed to the exact moment they are taken into account by real hardware. And it also highlights current position of the 'beam'. Very useful in testing time critical stuff. Simply set the breakpoint to the place where you are changing DLIST, and it will show you how the screen looks and where is the beam in the moment you are doing it. Then it has 'debug screen', which shows any screen at any time, typically your 'background' screen. You just set the DLIST address, and you can check how you background rendering is doing. Not to mention other useful tools like instruction history, asserts, memory write breakpoints and many more. Sure, Atari 800 has it uses, but for development, if you are not using Altirra, you're doing it wrong.