abandoned #11878
abandoned #11878
Conversation
|
This is the most barebones possible, I've been wanting to do this for a while, but frankly the state of the documentation of the dumps is a mess. For all the championing of the scans that were done and put on archive.org there are significant gaps in the documentation, mismatched PCB pictures with carts, missing PCB pictures, duplicate PCB pictures PCBs shown with numbers that don't correspond to the dumps we have, even if we seem to have enough dumps to cover all the games. etc. As a result, I can't say for certain even which game is which so the softlist just uses the part numbers. the dumps had. (also I can't find the CPU documentation anymore either, it should probably be linked in the skeleton for if somebody wishes to make a start on the emulation) |
|
http://www.seanriddle.com/cassettevision/CassetteVisionPCBs1F.JPG suggests Galaxian should be 006, there is no 006 dump. It also has 2 game names on the 774C silkscreened cart, but we only have a single 774C dump (is it a multigame ROM depending on something external? - in that case we have more dumps than there are games though?) This Galaxian is missing the front PCB scan This Battlevader shows 009 https://ia601906.us.archive.org/10/items/battlevader-epochcv-hiresscans/Battlevader%20-%20PCB%20Front.jpg I think the only way this is going to get sorted is if we get the ball rolling with it |
|
1 Yosaku = 005 |
|
maybe we're missing an earlier 006 Galaxian then? not sure why it would be silkscreened as that on the PCB unless there was a revision using it. Also it's strange that the 774 cart has "TV Vader & Yosaku" silkscreened on it. Maybe there's a 774 version of Yosaku too? I think New Baseball is 002 based on Sean's scans and the silkscreen. |
|
I've updated them to have names based on those numbers anyway |
|
Can you add a note about 10 being unreleased instead of 'not dumped'? As for the whatsnew list with credits, you'd have to ask Sean who donated/borrowed him the carts. |
|
I've talked to other people who say it was released, just very uncommon. I'd rather not add random 'unreleased' tags on things. I already made this mistake with one of the JAKKS gamekeys, and now people want a fortune for it. (FWIW it's one of the Star Wars keys, that we have a ROM of from the developer, but I was even told then it wasn't released, yet a number of people have the physical product, complete in sealed plastic packaging etc. - Likewise some people are claiming the Toy Story 3 Zippity game is unreleased, yet there are videos of that on YouTube from back in the day, so that definitely got distributed too) |
|
As for credits, if you have a list / can get a list I'll add it (although I don't even know current policy for such things) |
|
also if you have the CPU docs links, do let me know, I can't find the links anymore (was temped to do a disassembler) |
I don't have a list. I know Sean worked on these. So you could ask him. |
those are for the Super Cassette Vision, not the same. |
I've checked to see if he has any of those things |
…mat, which seems to flow from 0x7f to 0x80, not 0:7f to 1:00 but probably the best we can do?
…evice that includes it but has the video parts
… have to go directly in the main CPU core
…idea of what is going on)
|
|
|
|
| uint8_t temp = prgbase[i + 0]; | ||
| prgbase[i + 0] = prgbase[i + 1]; | ||
| prgbase[i + 1] = temp; | ||
| } |
There was a problem hiding this comment.
Or is it just a matter of changing the cpu device endianness?
There was a problem hiding this comment.
is Endianess really a thing in this case? it's a single 12 bit byte? I find this a little confusing.
There was a problem hiding this comment.
Here it'd just be for letting MAME know the byte order for each ROM word. TMS0980 and HMCS40 are similar, with 9-bit and 10-bit ROM words.
There was a problem hiding this comment.
I can look into that then.
Btw, do you think it's worth reducing down the pattern ROMs?
currently those are stored as sequences of 11 bit values, when in reality most bits aren't used (the first 0x70 characters are 7 bits wide, the last 0x10 characters are 8 bits wide)
I think it's stored as 11 bit because it was read out through 11 pins.
There was a problem hiding this comment.
I changed everything to 'big' and the swap is still needed, I must be missing something here.
There was a problem hiding this comment.
I see, that's weird. Just add a TODO note then.
src/devices/machine/upd777_dev.h
Outdated
| required_device<palette_device> m_palette; | ||
| }; | ||
|
|
||
| DECLARE_DEVICE_TYPE(UPD777, upd777_device) |
There was a problem hiding this comment.
Unless MCU embedded peripherals exist as separate chips (eg. Toshiba Z80 with built-in CTC), they can be implemented in the CPU device.
There was a problem hiding this comment.
interesting, I was always told to keep video stuff out of the 'cpu' folder in the past
There was a problem hiding this comment.
Why? Only for video? I don't see how that makes sense while at the same time having eg. the versatile serial controller for Hitachi H8 or HD6301 in the CPU device.
Or, see the LCD controller in SM51x or the HT11xx that you recently added, that is video.
There was a problem hiding this comment.
well one of the previous rules was that things in CPU should be somewhat usable outside of MAME, with minimal effort, so using MAME specific video type stuff was considered bad.
If that has changed, fine. I might still keep them in different files, for organization sake, but can put the _dev files in the CPU folder.
There was a problem hiding this comment.
I'm not aware of such a rule. Maybe you mean it was the opinion of someone that gave feedback on an older PR of yours.
There was a problem hiding this comment.
well given the amount of contradictory 'make it up as you go along' feedback I seem to get, that wouldn't surprise me.
… this code as my own, and would now be ashamed to put my name to it.
mamehaze
changed the title
No description provided.