Home Page Forums Active Threads

Finally figured out how to zap the gumball bombs.

I can't find any manual on the net, but this is what I figured out:

CTRL+K for keyboard, S/F for left right, D for stop, E/C for factory speed up/down, Return for crosshairs, Space for flip valves
CTRL+J for joystick, button 2 for crosshairs, button 1 to flip valves.

When an exploding gumball shows up there's a warning sound, locate the bomb, bring up the crosshairs and put the crosshairs in contact with the bomb and it will be zapped.

The exploding gumballs don't show up until Thursday.

The crosshairs initially appear over the corkscrew so if you can make the bomb go up the corkscrew you can just activate the crosshairs.
There's also a flashing countdown timer for the bomb in the upper left and you may be able to wait for it to go up the corkscrew.

A pretty good strategy is to use the left chutes as much as possible early on as you can clear the gumball out quickly. If you let it take the long path you have to keep an eye on it and it gets hard to track it with the incoming gumballs. You have to ramp up the speed to keep up with the quota, but don't set it too high that you make mistakes and see the quota get bigger.

I figured out the difference between illegal and illegal2 handlers: the logerror print message for the former prints 1 byte for opcode, and the latter prints 2. This means the mistake in the prefix 40 table was effectively completely harmless, just making some error messages in MAME slightly wrong.

Added a couple of useful modern'ish devices for the MTX machines.

Firstly, the MAGROM, a 512K cartridge system containing many games for quick loading. Various ROM images for the device have been softlisted.



Secondly, the CFX System, a Compact Flash storage device.

Also softlisted bootable CF images for:
CP/M

Fuzix

and we can finally run Hex-Train (contains over 200MB of pre-rendered graphics)

Cool, I'm going to have to figure out how to build total replay on linux so I can try the latest.


One weird thing, I was trying Gumball (having watched a video on youtube) and when playing with a joystick I can speed up production with joystick up but can't slow down production with joystick down.

If I hit CTRL+K I can do up/down with (E and C) left/right (S and F) D to center, Return to toggle crosshair, Space to flip valves.
CTRL+J for joystick.


Running applewin under linux with wine, the joystick can do up/down, but under mame only up seems to work with gumball.

Are you able to catalogue them ie which operating systems and versions?, languages?, diagnostics? etc have the potential to be preserved?

I don't know if I can offer any insight on that particular thing.

I was going great on the RX80 and it was all pretty much working except for going off into the weeds and running the carriage completely off to the right. After resetting it, it would work just fine.


I started looking at EOM as a possibility and the datasheet says in figure 6-4 "If LV0 level inversion is enabled and either set LV0 or reset LV0 are enabled, the set or reset will override the inversion. Inversion will only work with LRE1 = 0 and LRE0 = 0. The same concept is true for LV1".

Now if I modify the void upd7810_device::upd7810_write_EOM()

to implement that, it *really* doesn't work...and they also give a diagram at 6-2 of the output control circuit showing LRE0 and LRE1 connecting to the S and R of the Master/Slave FF.

Vas, I just figured that out as well, the upd78C10 document conflicts with itself; the diagram on page 93 (11-2 document page) matches what MAME does, while the documentation of the MOV opcode itself shows things the other way, which I'm assuming is just another documentation error like the SSPD thing.
Golden Child might be able to chime in since the printers they're working with probably do use those opcodes.

I thought the first longer morphing CGI movie was this:

John Whitney - Arabesque (1975) early computer graphics

In Germany in 1970th/80th there was a famous family gameshow "Die Montagsmaler" (The Monday's Painters), in that a person had to quickly draw an object (that he got told as a word) that other people had to guess before the timer runs up. The special thing was that instead of a chalkboard it employed one of the very first lightpen computers named "Telestrator" that apparently got fed with a punchcard to display to the spectators the word of the object to be guessed. While nowadays tablet computers with touchscreen and pen are common, until 1980th it was very unusual to draw directly on screen, and the show was such famous that in Germany until 1990th everybody associated the use of a lightpen (on C64 etc.) with Montagsmaler (much like in Britain the appearance of a police box got associated with the TARDIS of Doctor Who). Kids at schools often played the game during break/recess on the classroom blackboard.

https://de.wikipedia.org/wiki/Montagsmaler

DIE 1. Folge DIE MONTAGSMALER mit FRANK ELSTNER

There are many other clips on youtube.

I tried hard to find out how this primitive graphical "computer" worked. Apparently it used a persistent vector monitor CRT similar like an analogue storage oscilloscope filmed by a TV camera, and the ticking clock dot frame around the screen likely was just a kind of B/W luma-key effect (greenscreen predecessor) superimposing the picture of a clock made from lightbulbs and relays (and a contact wheel?) with the filmed vector screen. Telestrators were originally used in USA mainly to comment sports on TV for marking the position of players and ball etc. and were invented already in 1950th.

https://en.wikipedia.org/wiki/Telestrator

Here are some patents (websearch the numbers) I found about related hardware:

Telestrator_writing pickup_US2986596.pdf
Telestrator_superimposed dynamic tv_US3617630.pdf
Telestrator_electronic pointer for tv images (lightpen)_US2487641.pdf
Telestrator_AV teaching system&response_US3718759.pdf
teaching system with tv receiver_US3671668.pdf
optical graphic data tablet_US3761877.pdf
multiple camera superimposed message_US3580993.pdf
lightpen_telewriting apparatus_US3089918.pdf
lightpen_operation on remote computer_US3543240.pdf
lightpen_electron beam sensor_US3413515.pdf
computer graphic using video phone_US3584142.pdf

I think you’re wrong. The SFR codes are in a table on page 21: https://www.cpcwiki.eu/imgs/4/4b/UPD78C11A_Datasheet.pdf

• TXB = 011000
• TM0 = 011010
• TM1 = 011011

This matches the code in MAME.

Up to MUL now.
I found 2 bugs in the upd7810_table.cpp file while fixing cycle timings:
1. The first few prefix 40 opcodes are calling the 1-byte &upd7810_device::illegal handler instead of the 2-byte &upd7810_device::illegal2 handler, I don't know what sort of havoc this would cause since it only affects illegal opcodes. Because the opcodes have a prefix byte, they are 2 bytes long, so it should (if I'm understanding this right) call the illegal2 handler.
2. The more serious issue is a probable bug with the prefix 4D opcodes MOV_TXB_A, MOV_TM0_A, MOV_TM1_A, and MOV_ZCM_A which I'm pretty sure (based on the upd7810 instruction set databook) are in the wrong order in the table, causing the wrong opcodes to execute!
EDIT: scratch #2, the documentation conflicts with itself; I suspect the current order of things are correct since otherwise I suspect stuff would work much worse than it already does, if it has to do with serial communications and zero cross timing. Golden Child, correct me if I'm completely wrong here.

LN

So I was watching "The Ascent of Man" from 1973 and it has some interesting computer graphics, some animated line drawings.

Bronowski sat in front of an IDI Information Displays Inc terminal that's labeled "Computer Controlled Display".










They were pretty expensive back then.




It's fun to read about the technical details of similar terminals:

https://archive.org/details/TNM_IDI...lays_Inc__20170920_0060/page/n1/mode/2up


The computer graphics were done by Peter Foldes who did the film "Hunger" that used tweening. Really trippy.



At the 7:10 mark it reminds me of the Amiga SpaceBalls State of the Art Demo.

Cool, thanks. Might save me a step. Never thought to google a workaround .

You can still get blocked gmail rar files using the 'show original' and 'download original' functions, then open the eml file with a 3rd party client.

PM sent!

It looks like I might have to dig on some old hard drives to fully get the data. My gmail has the important .rar as an attachment, but google has decided it's got a virus and I can't download it anymore. And the file i put up on mameworld 10 years ago seems to be missing now too. Oh well. I sent you some wayback machine links, but lemmee' know if you want *all* the stuff and I'll take the time to dig it up!

/Andrew

Personally, I'm rather interested in getting that core up and running as well. Any junk is appreciated.

The annoying thing about the DSP56156 is that it's more or less completely different from the DSP56001, which is another thing that's completely missing in MAME: Having a DSP56001 core would, at a minimum, allow audio emulation on the SGI Indigo, remove what will eventually be blockers for improving NeXT and Atari Falcon emulation, and potentially make life easier for implementing one of the Digital Video Cartridge variants on the Philips CD-i.

The Motorola DSP56156 that's used in Konami's Polygonet Commanders and Polynet Warriors is *very* close to doing what it should. I ran out of time years ago to finish it off. The code is in a really weird state right now though. I was trying to do some abstractions in 2010 that modern C++ probably do much more easily.

The specific CPU can be a little frustrating working with because the documentation can be off in parts, but there *is* plenty of documentation, a few documentation addendum, and a win16 simulator for it, that can all be referenced. I wrote some python scripts that would exercise the simulator in ways that MAME exercised the core as well. It should be a fun project.

The MAME CPU core is communicating with the main CPU well enough to upload a bunch of 3d model data to the right spots - the dsp56156 just isn't grinding through its calculations yet. (see post here called "Polygonz attack" - https://mameworld.info/ajg/ ). If i remember right, it's getting stuck in a loop because i don't emulate one of the loop instructions right? Hard to recall.

I can try to dig up all the junk I have that would help in its emulation, if you're curious.

I'm up to EQAW (in alphabetical order) in the upd7810 databook, fixing the timings in upd7810_table.cpp. I haven't migrated all of these fixes to the upd7803 and 7807 though, although some of them are obviously also wrong there.

The MAME CPU cores that need the most work, to put it plainly, are those that haven't been added except as stubs. Lately I've started work on real emulation for Motorola's CPU16 (M68HC16), which is a sort of low-end 16-bit DSP loosely based on M68HC11. As usual, I'm implementing it as an enormous state machine, which was perhaps not the easiest way considering the numerous addressing modes for all of the arithmetic and logical instructions.

For those architectures which have enough of the instruction set emulated in MAME, the problem often becomes the lack of emulation for on-chip peripherals. UARTs are indeed a common omission, and MAME's MCS-51 core indeed particularly suffers from the lack of a proper UART, but they're critical mostly for certain applications that tend to demand them, such as MIDI synthesizers and video display terminals. Many other MCUs and SoCs have UARTs that are used very little (ST2XXX) to not at all (RISC II) in systems that have been dumped.

Timer blocks have been emulated more often in MAME, but a fair number have still yet to be added. KL5C80A12 is still missing one of its two timer blocks, and I plan to add that someday because it's a probable blocker for consolidating the Sammy medal games and running their Flash setup menu from the BIOS (which was formerly simply bypassed but now is hacked to run just enough code to initialize a few critical registers). The Atari CAGE emulation is rather messy right now because a whole bunch of TMS320C31 peripherals lack proper emulation, including the timers. The "PSX" CPU emulation is missing cycle-by-cycle DMA when I last checked, which is a blocker for replacing a whole set of legacy SCSI devices with modern counterparts. The MN1880 emulation I've written is now badly in need of interrupt sources from timers and other on-chip peripherals; it would help a lot if some documentation for that Panasonic MCU family were to turn up with more details on those than the mere summary sheets now available. (If those aren't forthcoming, my best guess would be that some of the timer registers might be similar to those of other Panasonic MCUs from the MN1870 and MN101 families.)

Dtech wrote me in 2012:

And regarding rom contents playback as samples, I discovered that "My Music Center" toy keyboard hardware (Holtek - Ad-lib Micro®, may be HT3670 based) by shitshot (voltage glitching) often vomited apparently its entire rom contents through the DAC, producing a sequence of all samples with "noise" in between. Because its MCU is SRAM based, its resistor controlled clock rate can be turned down to complete halt with crash, which may permit to sample the output (which DAC multiplexes polyphony voices like Yamaha) precise enough with any PC to decipher it.

Night Flight is the game that became Battle Cruiser after adding Mockingboard support, and maybe some other features.

Apple Cider Spider should play through the Mockinbgoard without Ctrl-B. It definitely does in the current builds. Maybe I fixed something since v4.
Battle Cruiser requires a speech chip, the same as Rescue Raiders. The TR version of both will disable the Mockingboard if the speech chip isn't found.
If your version hangs then I must have fixed it in the meantime. I just checked the latest build and both run as expected.

Hi LN,

Yes, there's a bunch of cycle counts that aren't exact. I think that it's probably the PTS sensor that's the problem as the cpu runs much faster than the mechanical movement.
Anything's possible, I won't rule anything out 8-)


I keep having trouble with the mx80 and the alignment. I've got the PTS multiplier value set to 1:1 and that seems to fix the graphics, and mess up the text. If I set to 1:2 that fixes the text and messes up the graphics.


Graphic printout with 1:2 (clearly seems to be missing in between columns) at 120x72





Graphic printout with 1:1 (120x72) 120dpi horizontally is the mx80 limit. This looks okay without glitches.

I'm wondering if the cycle timing tables being wrong for the upd7810 and upd780x is causing some of the columns to be offset improperly in the printouts.
I have a local patch which partially fixes this, but I never made my way completely through the upd7810 databook to fix all the timing mistakes in the tables.

There's a LOT of mistakes!

LN

I know how it can be done in a general theoretical sense, I'm more wondering how it might have apparently already been done with the MSM6387, especially because it's just a tiny little DIP30 with no external memory bus.

If D-tech has one decapped already, did he actually use any kind of exploit at all or did he just read it from a die photo?

The usual way it to find an exploit to trick the system into treating program ROM as audio samples. This was done for some arcade games to extract the internal ROMs from the sound CPUs. (Speaking of which, you can exploit the QSound DSP to make it use any old piece of program ROM as FIR filter taps. In conjunction with a specially-crafted sample ROM, that could be used to extract the program ROM as a digital audio bitstream. We should do this at some point to verify the ROM contents. There are three bit errors in it that I know of, but there could be more.)