JohnPCAE

raycast_20200313.zip Even MORE speed, fixed a crash, and it takes less space.

raycast_20200312.zip MORE SPEED! (changes to colored-squares mode only) With all the loop unrolling this has, I'm running into space issues and I had to remove more dead code. This version, however, has much better performance when dealing with walls that are far away. That said, I don't know how much more this can be sped up while still using "plain vanilla" hardware. My intent has been to squeeze every bit of execution speed out of it before looking at adding features that could slow it down, such as texture mapping, "holes" (e.g doorways), and mazes larger than 16x16 squares (by tiling multiple mazes).

raycast_20200309.zip Drat. I found a potential bug in the code that could cause a crash, so here is a new version. It's not all bad, though: I also eliminated a bunch of overhead from the colored-squares ray caster so it will run a bit faster.

raycast_20200308.zip Slight speedups to both the card-based and the colored-squares code. I also removed a lot of dead code (older multiplication routines that didn't use quarter-squares multiplication).

Ordered!

I wish I'd gotten one but there's no way in hell that I'm paying $200 for it.

That sounds like the same sort of learning curve, though.

The hardware part of this project is very nearly finished. I need one more board revision (due to having the enable pin logic reversed), but everything else works. At this point, I think I need advice from the community. As it stands, anyone with basic soldering skills can build this as it uses only through-hole construction, but between the board and chip costs it's pretty pricey. An FPGA solution would be much better, and probably wouldn't need an external power supply like this does (the switching power supply component alone costs about $40). Turning this into an FPGA isn't in my skill set, though, and I'm not sure it makes sense to spend the next couple of years trying to climb that learning curve. So I'm wondering if anyone here has any ideas. As for the software side (yes, there is one), the microcontroller code needs an update, but it's not particularly hard. At present it only supports text mode and I'd have to slightly expand it to support the three graphic modes. It's a pretty trivial change. I also want to add support for things like scrolling and column blanking, which is also a pretty easy change. The microcontroller (which isn't visible in the above picture) is a Sparkfun RedStick. I chose it because it's basically an Arduino Uno in a tiny form factor and doesn't require a cable to program as you just stick it in your USB port. That's actually one of the cheaper components in the setup: the IDT FIFO and dual-port RAM chips are the expensive parts. One thing about the software is that you can't use the Arduino IDE to create it. The problem is that the machine code it produces is just far too inefficient. I'm using Atmel Studio 7 and everything is written in assembly. That's the only way this can work.

Is the game totally sold out? Will any more be made?

Drat! It says its out of stock

I'm running this on my LTO Flash to test my video overlay project and I'm seeing something weird. I'm using it to inspect memory in the D000-DFFF range as that's where I expose my video buffer. What I'm seeing looks a lot like bus contention: it looks like the boards are trying to output the memory contents, but the memory probe is always seeing $FFFF. Is it possible that the flash cart is forcing all the bits to 1? Is there something I need to define, say in the .cfg file, that tells the flash cart that range D000-DFFF is supplied by an external device? *sigh* I think I found the problem. I had the dual-port ram mistakenly wired to always output high-Z to the Master Component. Time to order a board revision...

This makes me wonder if the developers had a special controller box that interfaced into the controller ports for making it easier to use the debugger, i.e. something with a layout specifically designed for debugging use.

The final boards are built. So far I'm getting good video, but the whole stack needs to be fully tested (changing the video contents from the Inty). Then I have to update the microcontroller code to support all five screen modes. Already I think I see one problem with the enable pin (video should be disabled by default), but that's a simple thing to fix in a later revision.

Insomnia and allergies are conspiring to keep me awake so I figured I'd write up an idea that's been in the back of my mind for the past few months. One of the fun parts about programming for the Inty (and many other retro systems) is having to work within the limits of the system, such as size or speed constraints. With modern bankswitching we can make an Inty game almost as large as we want, and we even have some simple math acceleration available like fast multiplies. This is an idea about taking it to the next level. We know that the CP1600 only requires 10 bits of memory for its instruction set, but a really intelligent cartridge could use those extra 6 bits to extend the instruction set within its address range. By "really intelligent" I mean a cartridge that listened to all bus traffic to and from the CPU. For every instruction the CPU executes, the cartridge maintains a mirror of the CPU's internal state. Basically a microcontroller on a cartridge. The microcontroller would also be responsible for providing data from the cartridge's address space when the CPU requests it, i.e. serving up the game code and data. This would enable some really powerful things. 1. Simple example: inclusive or instruction XORI data, RD is encoded as 1111 111 ddd. We could extend it to mean 000000 1111 111 ddd, so that whenever the upper six bits are all zeroes the instruction remains the same. We could then decide that encoding 000001 1111 111 ddd would mean ORI data, RD. Since the microcontroller would always know the state of RD beforehand, it could always supply the correct "data" value to achieve an inclusive OR result even though the CPU would *actually* execute the original XOR operation. And, since an XOR is being used, the condition flags would also be set. Taking it a step further, we could do something like this: 000000 1111 111 ddd XORI data, RD (original instruction) 000001 1111 111 ddd ORI data, RD 000010 1111 111 ddd OR R0, RD 000011 1111 111 ddd OR R1, RD 000100 1111 111 ddd OR R2, RD 000101 1111 111 ddd OR R3, RD 000110 1111 111 ddd OR R4, RD 000111 1111 111 ddd OR R5, RD 001000 1111 111 ddd OR R6, RD 001001 1111 111 ddd OR R7, RD The CPU would see all of these as XORI data, RD, but the microcontroller would supply the appropriate data value to achieve the desired result. It's even possible to extend it to indirect memory addressing using [email protected], provided that the memory being accessed is also within the cartridge's address space. 2. Other instructions that place a result in a register For something like a MUL instruction, instead of basing it on an XOR operation, extended instructions could be based on something like MVII data, RD. This wouldn't set any condition flags, but it also wouldn't have any unwanted side effects. On the other hand, if one *wants* condition flags set, sticking with XOR would work just dandy. 3. Advanced idea: redefinable instructions Instead of hard-coding the extra bits to mean specific instructions, it could be left up to software. How? By using an extended no-op instruction. The CP1600 has four (!) methods of achieving a no-op: 0000110100 NOP 0000110101 NOP (2) 1000001000 NOPP 1000101000 NOPP (2) One of these could be extended to supply special meta-instructions to the microcontroller for defining how certain instructions are extended. Here's a very simple example of a meta-instruction format: 1111111000 0000011111111xxx 0000000000 0000 The first 10 bits specify a mask telling what parts of the basic opcode are relevant. The next 16 bits specify the extended opcode (where x's could be either 0 or 1 since they will be ignored because of the mask). The next 10 bits specify the operation to take place (XOR). The final 4 bits specify the source operand type (0=immediate value) The 40-bit meta-instruction could be encoded in a string of 10 NOPP instructions: 01 1111 1000001000 10 1110 1000001000 10 0000 1000001000 10 0001 1000001000 10 1111 1000001000 10 1110 1000001000 10 0000 1000001000 10 0000 1000001000 10 0000 1000001000 11 0000 1000001000 The first two bits are markers that (1) ensure that the upper six bits are never all zero and (2) signal the beginning, middle, and end of a meta-instruction. The next four bits are the payload, and the last 10 bits are the normal NOPP instruction. This scheme would let a microcontroller support a vast amount of potential instructions while letting a programmer choose those instructions he needs. A programmer could even redefine instructions as the needs in a program change. The concept in fact starts to blur the line between writing instructions and writing *microcode* for instructions.

I designed that board layout myself specifically to fit in the Inty II. It has the same circuit as the one from Turkey. As far as I know, no one else is selling them, so it's DIY. Black connector: https://www.mouser.com/ProductDetail/Switchcraft/PJRAN1X1U01AUX?qs=sGAEpiMZZMv0W4pxf2HiV7sv6uhfrItvDW4M8xvx2XY%3D Yellow connector: https://www.mouser.com/ProductDetail/Switchcraft/PJRAN1X1U04AU?qs=sGAEpiMZZMv0W4pxf2HiV7sv6uhfrItvBsNHR2KsS%2BQ%3D Resistors are all 6.3mm 1/4W 1% (typically Yageo) 100uF MLCC Capacitors: https://www.mouser.com/ProductDetail/TDK/FG20X5R0J107MRT06?qs=sGAEpiMZZMvsSlwiRhF8qjQUafaa8S5xxY5jaNk54ifokfPwqQzMNg%3D%3D 100pF ceramic/MLCC Capacitor: https://www.mouser.com/Passive-Components/Capacitors/Ceramic-Capacitors/_/N-5g8m?P=1z0x7xgZ1z0z7l5Z1z0wljoZ1z0wpn9Z1z0x6fr Transistors: https://www.mouser.com/ProductDetail/Central-Semiconductor/2N3904?qs=sGAEpiMZZMshyDBzk1%2FWiw99kSkYzPxmf7NzGOknJzA%3D The TDK 100uF capacitors I used are to be discontinued but Mouser has lots in stock. Any of these should do, though: https://www.mouser.com/Passive-Components/Capacitors/MLCCs/_/N-bw5rv?P=1z0z7l5Z1z0wrkm