Asmusr

I enjoyed watching it, but I think the importance of technology advancement for game development should have been more clearly stated. I didn't like the intermezzos of pseudo pixel graphics and would rather have seen more footage of the actual games. But it's great that Netflix choose to do a series on a topic like that.

In my project I choose to leave it on because I'm not going to access any DSRs. But what happens if you leave it on and then enable the disk DSR, for instance. Will a read to >4000 read the SAMS register or the disk ROM?

Using the imaginary switches, of course.

Pages and banks are the same thing. I don't know what they meant by frames. What do you mean by "advance banks of >3000->3FFF"?

The idea of adding a bank is not quite right. By writing to >4006 you choose which bank is mapped at >3000, but you don't add anything. Edit: and if you add to the number stored at >4006 you just choose another bank.

I'm sure I have been burned by assuming a start-up stage when the mapper is turned on. I think Classic99 is setting this up, but it's not what my hardware is doing, which has an older SAMS card. Also, if another program has been using the SAMS before, you cannot assume anything.

You should not assume anything about the state that the SAMS starts up in. If you want to start with bank 2 mapping to >2000, bank 3 mapping to >3000 and so on that's up to you. If you don't set up the start up stage yourself you will get in trouble.

I still find the idea of developing a very low bandwidth video encoding protocol for the 9918A interesting. Edit: I found this, just for fun: https://gizmodo.com/hacker-figures-out-how-to-capture-horrible-quality-vide-1842660879

Since you ask for it. 🙂 You know how slow it is to load a program from cassette. A bitmap image is 12K. How long does it take to load a 12K BASIC program? A few minutes? And we want to load several images per second. Even with the most clever optimizations I think it would still be a thousand times too slow.

Yes 64x192, with fat pixels that are 4x1 normal pixels. This is the highest resolution where you can set the color of each pixel independently. To work with a resolution of 128x192 you would have to cast twice as many rays, upload twice as much data to the VDP, and spend a lot more time drawing each pixel. Do you know the limitations of the 9918A bitmap mode, that you can only have 2 colors per 8x1 pixels? You would have to keep track of that and decide which colors to use. When you draw in this mode by hand you can arrange your drawing in clever ways to work around this restriction, but in the raycaster the program would have to make quick decisions, and the result might not look better that what we have now.

Maybe you could get a better result, but I don't have any way of producing those backgrounds, and it would mean starting all over again. This project is going in the direction where the possibilities take it, and the chance it will end up as a version of EOB is close to zero.

In this low resolution (64x192) with only 16 colors you will get aliasing errors where details disappear. The earliest texture mapped games like Wolfenstein were using 320x200 in 256 colors.

Here we go. It's skipping drawing and upload of columns where the wall has unchanged height and texture. It's also skipping upload of the top and bottom 3rd of a column if the wall height before and after is lower than 64.

Not yet.

Since I started with a ZX81 clone, then got a TI-99/4A that I sold around '83, then dabbled with the ZX Spectrum and C64, and finally got an Amstrad CPC in '84, I can't say that I disagree much with the list. 🙃 I never got an Amiga but went for a PC compatible instead.

I do once in a while make something like a unit test when I have an isolated function that's doing something quite complex and returns a simple result. But I delete the test code again instead of building a suite of tests the can be run again later. It's often difficult to isolate your test unit because global state is used, and mocking your dependencies would be quite difficult. Maybe it would be different if I was writing libraries instead of games? In games I often don't even have the option to print the results of asserts on the screen. Perhaps I don't even have an ASCII font? And maybe my function requires keyboard or joystick input? One thing I have been dreaming of is to be able to tell an emulator to print out asserts or expressions to a log at given points in the code. You would place the asserts in you code, and the assembler would output them to a separate file that could be loaded into the emulator. I think that would be a great tool to complement breakpoint debugging, and it could also be used for unit tests.

No I didn't optimize the VDP transfer yet.

I shouldn't have mentioned a particular use case in a general challenge. But thanks for the feedback everyone. I conclude that there isn't a clever way I have overlooked to copy words between even and odd addresses, and that the general solution will need to have branches for several special cases.

In this case I would have to add 16 more ROM banks for a bit of performance.

But that won't work if the source and destination words are not aligned 🙂.

I have no idea what I was supposed to do, to be honest. 🙂

I implemented the incremental drawing of the floor and ceiling that @artrag suggested, and the frame rate is quite good now when you move in the same direction. I also adjusted the movement so you are always placed in the centre of a square. That helped with the sliding of floor texture relative to the walls, but did not solve it completely. There is a small issue that you can see at the end of the video: because I'm drawing all even column pixels as movb (with the right nibble zeroed) and the odd column pixels as socb (like OR, with the left nibble zeroed) I really need to draw both the odd and even pixel next to each other for the correct result, but when the height of the wall in the two columns differ I don't draw both pixels at the top and the bottom, so the result is a few pixels with wrong colors. Drawing the pixels 'correctly' by first removing the old pixel with szcb and then setting it with socb would take twice as long, so probably not worth it. A bigger issue is that because I cannot execute code in one ROM bank that reads data from another ROM bank I either have to give up some of the optimization, or invent a new ROM cart that can bank switch two 4K banks independently, or move to SAMS. I'm reluctant to do the latter because I don't really need more RAM - just the bank switching - but it's probably the path I have to take. texcaster8.bin

For use in my raycaster project, I present this challenge: write the fastest possible routine to copy any number of bytes (even or odd) from any address in CPU memory (even or odd) to any other address in CPU memory (even or odd). The ability to handle both odd and even addresses is essential, and exactly the specified number of bytes must be copied. There is no need to support overlapping memory regions. Self-modifying code is acceptable. Here is what I'm after, only faster: * r0: source, r1: destination, r2: count copy: movb *r0+,*r1+ dec r2 jne copy rt

I'm not dedicated, and I don't have time. 🙂

Right. So the diagonal speed has to be sqrt(2) instead of 1 for the floor to be fixed.