new machines marked as NOT WORKING - Cassette Vision

[mamehaze]

This is a fresh, squashed PR for the work done on Epoch Cassette Vision.

It's free for anybody who wants to pick it up, as I don't feel comfortable working with this design, as it loses a number of important benefits from my original one.

[mamehaze]

For reference this is the state I'm leaving this in https://www.youtube.com/watch?v=kTWdtXbN97w

You can see that games like Elevator Panic and Monster Mansion seem to run a large part of their game logic, as does Pak Pak Monster.

The 'repeat' sprites (x and y) used for columns and screen length platforms aren't rendered as such, hence why there are sometimes just short blocks where there are should be longer platforms.

The exact behaviour of 'skipping' seems to be important, as my earlier research pointed that in some cases it seems that you need to skip changing the 'L' (memory pointer) value. The document in some cases also words things differently eg.

"Subtract A1[7:1] and A2[7:1], store to A1[7:1], Skip if borrow, N->L[2:1]" vs "Subtract M[H[5:1],L[2:1]][7:1] and A1[7:1], store to M[H[5:1],L[2:1]][7:1], N->L[2:1] Skip if borrow"

so it could be this indicates a different behaviour when it comes to the setting of L depending on the skip. (in addition to the obvious skipping of the next opcode)

The H<->X opcode must do more than handled, but I'm not 100% sure it's important for getting the basics running. Inputs could probably be added via a combination of implementing the STB (strobe/shifter) and the KIE reads (currently it just returns a single fixed 7-bit port)

The VBLK opcode it seems should also clear some of the memory in some cases according to the document.

The sprite rendering should probably be made scanline based, and based on what has been sent to the 'line buffer' with the "Move H[5:1] to Line Buffer Register[5:1]" opcode. Currently the driver just renders the sprite registers in full.

I think if somebody is so inclined, these could at least be made playable in a basic sense (you can already move the character around in Elevator Panic) with a bit more studying of the disassembly and verification of the opcodes.

I'm not really happy with the state I've been forced to present this in now, but since others have also expressed that they find it easier to read in this form (I really don't know how) versus the larger switch/case statements it's where I'll be leaving it and I'll that preference as an indication that they would rather finish this off than leave me to continue with code I'm more comfortable working with.

[mamehaze]

https://www.youtube.com/watch?v=DszAwq6Z4g0

Also I hadn't realised this at the time when I made the first video, but if you attempt to start Astro Command, and speed it up, you can tell it's a scramble clone as the buildings scroll in (again heights are wrong as it's meant to be using the 'repeat Y' attribute some sprites can have somehow to turn single sprites into buildings.

It even cycles through the stages and boss logic.

PakPak monster, while you can't move, does let you point the character in left / right directions. If an enemy touches you, you do die.

Elevator Panic actually lets you finish a stage, and ride on top of the lifts, fall down the holes etc. although you start in the wrong place, and can jump up where you shouldn't be able to.

Monster Mansion lefts you move left / right, but there's no way of climbing the ladders.

Baseball lets you swing and hit the ball (New Baseball doesn't, maybe it's a fielding game instead?)

There are probably only a few opcode logic / understanding / decoding bugs away from these actually being playable, albeit with the graphics still being a mess.

[mamehaze]

so I think I've jumped through the last hoop here based on what other Mame Dev members have told me. I discussed this at length with another member, who thinks it's good enough, but is afraid to merge it, but that is how Mame development appears to work these days.

While I no longer recognize this code, and will struggle to work on it, hopefully it can be included so that the progress made so far (which brings the games close to playable) is not lost.

[cuavas]

I’ve fixed up the software list and cartridge load handler, and the unidasm data source now matches the CPU’s Endianness.

The big function for executing an instruction in the µPD777 core is really too big and needs splitting up. It’s going to need multiple levels of dispatch for the instruction decoding to make the code manageable. The disassembler has similar issues.

I’m not going to be able to do much more with it before the release. I’ll get back to it again after that.

[mamehaze]

you might as well nuke this now, there's not much of value.

there as a massive opportunity for MAME to make a big splash and leave a lasting good impression with this with this, being the first emulator for the system, but since it got completely derailed, others have taken that crown and there's nothing meaningful of value here anymore.

[mamehaze]

I've had a number of people express that they'd like this merged anyway so that the correct ROMs are part of the MAME set.