yes I can light up the VFD so long as the other parts are present. That's how I been doing the vfd captures so far; I wire them up so all the segments light using the power supply on the game
Self-test on this machine is very, very paranoid -- I think I've found a emulation bug in i8255.cpp
And there are two more bugs, apparently. Datasheet shows that INTR bit should go high only after STB is deasserted (goes high); and that asserting STB should always load data into input latch. With these changes, keyboard interface test is happy.
I don't have a lot of bandwidth but I do know Cocoa fairly well at this point. If there's something specific that you'd like me to look at, then shout.
Yeah, you don’t need to resolve if you set the delegate using a reference to an object and a function pointer. If you set it using something that gets turned into a base device and tag, you need to resolve it after you know that all device add/replace/remove operations are complete.
Hard Drivin was one of my favourite games on Amiga (Hard Drivin II) and DOS PC (Race Drivin). I also played the arcade machines (Hard Drivin and Race Drivin) a few times in my youth. In MAME I
This is the Hard Drivin hardware page by the original game programmer Jed Margolin, including interesting tech details. (The steering wheel motor is mains operated. He warns about the risk of deadly electric shock when messing with its circuitry.)
The Hard Drivin steering in MAME behaves a bit odd. Once the car started to drift for a while and left the road, it often keeps spinning on the grass like a carousel and becomes very hard to control for the rest of the game. I am not sure if this is a MAME or game bug, or if this was even intentional game design, simulating excessive tyre wear or other car damage affecting steering - possibly exaggerated as a penalty for bad players.
(I control it by mouse on a slightly underpowered laptop with 1.6GHz Core2Duo and Intel graphics. The game plays well but often at about 90% speed. Setting steering wheel sensitivity "6" works best.)
- car crash into invisible object
After on the "race track" the car crashes somewhere near the grey drawbridge, after the usual "instant replay" the car is dropped back onto the road (falling 1m out of the sky?) at a certain spot with the drawbridge in sight. But if I push the gas pedal (rolling about 1m in any direction) the car keeps crashing into an invisible barrier (windshield shatters), is dropped back on the very same spot and so on; crashing from there again and again until time runs out. I am not sure if this is a MAME bug or game bug or even nasty little prank played by a poorly simulated Slapstick chip.
notes:
Did you ever wonder what the "wheel" setting in MAME analogue controls menu means? According to the Jed Margolin site, this potentiometer likely senses the seat position to control force feedback intensity of the arcade steering wheel motor, because the designers concluded that a player who moves the seat to the front is physically small and thus likely a child or otherwise weaker than a big person who moves it to the back.
Race Drivin simulates more complex driving physics than Hard Drivin and so has a different DSP chip with floating point capability. That's why MAME needs more CPU power to emulate it. The programmer site mentions that the chip contains a funny little easteregg to identify if hardware pirates of a bootleg version really managed to copy it or replaced it with something else. That is to say, the firmware includes a crude SDR algorithm that after reset morses the Atari copyright message to a nearby AM radio.
Quote
If you ground pin 4 on the TMS320P15 (signal 'P2') and then reset the chip (turning the game off for a few seconds and then turning it on again will do the trick) the TMS320P15 will send the Atari Games copyright message in Morse code which can be received on a standard AM radio by holding it near the DSK Board. Tune around the AM band to get the best quality signal.
The Race Drivin hardware had serial networking capabilities to link multiple machines as side monitors for multi-screen view (which of course in MAME needs more CPU power). This website has hardware info and many photos about this feature.
Even more exciting is that there were professional drivin simulators based on it. In 1990th in the RGVAC newsgroups people claimed that Hard Drivin had begun its life as a drivin simulator before they made it into an actual arcade game. According to this website they also used it to train for other emergency vehicles. A 3-screen machine was used in research to test driving fitnes under medical conditions like diabetis.
Documented is the AMOS (A.G.C. Mobile Operations Simulator) by AGC Simulation Products, which permitted to link up to 8(?) Panorama-like 5-screen machines to a central workstation (PC with additional single-screen machine as monitor). The setup was known as the "Police Trainer" and apparently used for policemen to train car chases. The youtube video shows that the 3D object design (vehicles etc.) was done on an Apple Mac.
Atari Games Police Training Simulator
- rom dump of professional simulator?
Has anybody found eproms or software of those serious simulators or researched if there were hidden features in Hard Drivin or Race Drivin code to support such things? May the code e.g. load race tracks from an attached PC or (hence the name?) hard drive!?
Reminder: this thread is for OS install guides only. Posting questions here may result in a ban, please create a new thread for support issues instead.
I could, if I knew anything about scripting. I'd rather just ask a clear-cut question and hopefully get a reasonable answer. I don't think there's anything wrong with that.
That's why I'll be testing it on the real machine this weekend.
I've used wav files generated from cas files to load games on Dragons from my iPod classic (that doesn't have remote capability) on several events and never had a problem.
Of course, it may be just how the Dragon loading routine works.
I'm not trying to say that cas files are adequate for preservation, because they are obviously not, but we may find some interesting information that could help improve our understanding of these machines and its emulation.
I used environment variables to be able to use scripts to run several MAME instances with different IP/port configurations. Anyway, I agree that adding a menu to choose this might be more user friendly.
You can run several instances of MAME with different plugin data directories using the -homepath option. It’s also generally a good idea to use different NVRAM directories if you’re running multiple instances of MAME at the same time.
Originally Posted by bobz
JSON files are for the python client so they can't take advantage of MAME's UI.
If the user has to create/edit those JSON files at all, you’ve already failed on user-friendliness. If they can’t select a suitable input from a menu, it’s already well into “no-one will use this” territory.
Originally Posted by bobz
As for the field's names, I used them because I wasn't aware of cfg files tuple. I will take the risk of being slapped, but human-readable names seems more user friendly. I should let users choose between quick and dirty human-readable name or clean and stable tuple.
If the configuration breaks by changing the display language, it’s not user-friendly. If it relies on being able to type something from a visually ambiguous string, it’s not user-friendly. Consider things like consecutive spaces (used in the generated names for keyboard inputs), multiplication symbol vs letter x, currency symbols, and visually-similar letters.
Oh yes. At its time, the Archie was the only homecomputer that Amiga users did not mock about. (Atari ST was considered a bad joke and 386ers ridiculously overpriced and jerky). Archie had to do many things in software where Amiga had dedicated hardware, so at least for 2D games in real life both performed similar. Unfortunately it did not sell well outside Britain; In Germany I only remember 2 shops (the Brinkmann technology shopping center and a small store for electronic components) that had an Archimedes (A3000?) to try out, so most of us saw it only reviewed in computer magazines.
Exciting is that ARM CPUs (now found in every tablet and brainfryer) directly originated from Acorn Archimedes, and 1990th models were already SoC based, i.e. Raspberry Pi can be rated a direct Archie successor, and the RISC OS for it is still maintained. I read about it and like the philosophy (still very homecomputer, i.e. can run completely from RAM/ROM without swapping to disk, built-in BASIC, high CPU efficiency, no multiuser complications etc.) which sounds great for data minimisation to avoid data vampires and factory-prebugged devices. To me this feels right! - like the true native OS for RasPi. The mouse use paradigms differ from Windoze-like OS, but that's because it is older than Win95, and likely not designed for proper webbrowsing. But for a small separate offline machine it makes sense. May be its time to get a RasPi with enough RAM in a shielded case to flip the bird to all those data ticks sucking in the background of nowadays always-online IT.
This is perhaps not quite the same thing, but one feature I did a trial implementation of was "exception points", which lets you conditionally trap any case where the debugger exception callback is invoked. These cases potentially includes software traps, and I already updated the x86 and 68K CPU cores so that INT XXh and $AXXX instructions can be trapped. (The currently-existing gex command behaves similarly, but is a one-shot deal.) A secondary intention behind this proposed feature of mine was to simultaneously retire the special per-instruction debugging hook which is now used exclusively by the rmnimbus driver.
The thing is, MAMEdev the organisation is in violation of a number of their policies but gets away with it by virtue of being a “halo project”. It’s all bullshit.
