Development of module-script generator for lr-mess, lr-mame and mame standalone
DTEAM last edited by
Do you have experience with the "artifacting" setting ?
See here for some tips like Test your games at lower settings and set a max FPS if possible
jamrom2 last edited by jamrom2
So Artifacting was a term used to describe creating colors that didn't exist in old PC's. It was a way to make color graphics before VGA and RGB style monitors were around. In today's tech language, artifacting usually means a bad graphics card or something like that.
Here is a discussion on it over at the Atari Age forum using an actual Atari 800 computer. The A800/400/XL used artifacting especially in Hi-Res mode for games like Choplifter and A.E.
Here is a thread with very good examples from rkoster on our forum. I helped him with this and he had me testing all kinds of stuff on the lr-atari800 emulator. But scroll down and you'll see the examples, especially U3 Exodus.
What I see in Mess in relation to Dragon32 is that it's not displaying the artifacting at all. So you get black and white lined graphics. They should be some form of color.
The MESS menu shows that the artifacting is active, but has no effect on the actual graphics.
Folly last edited by
That is indeed very different than what I/we were thinking.
I found also a nice resource explaining what it is :
Definately an issue, but I don't see where it's coming from. East game to compare is to run Canyon Climber. Coco is displaying properly with colors and all, Dragon32 is not.
I wonder if the games have to be Dragon32 specific? I don't recall that being an issue between these two systems. The were interchangeable.
I think I might know what's causing this...
Dragon32 was for PAL format, while TRS-80 was NTSC. It might be that the games themselves are not triggering the artifiacting. I took the Balldozer game, which is for Dragon32 and tried it in the Coco2. It failed with a graphical error. Tells me the programs themselves might be machine specific.
Berserk works on both, but no artifiacting on the Dragon32. It's black and white only.
I think it's also for NTSC only.
The NTSC composite signal VS the PAL composite signal is very different in how the colors are transmitted.
Could be a plausible reason.
Have you tried these ?, perhaps they work different :
Driver d64plus (Dragon 64 Plus): @non-arcade@computer
Driver dragon64 (Dragon 64): @non-arcade@computer
Driver dragon64h (Dragon 64 (HD6309E CPU)): @non-arcade@computer
Look into the slider controls.
Screen refresh 50Hz is for PAL
60Hz is for NTSC.
Try changing setting from 50 on 60.
@folly I'll give those a try soon. Just working on finishing some data input for the Coco Theme
jamrom2 last edited by jamrom2
Found it. It was a bug in MESS as suspected. Apparently it looks like it was fixed, but I don't see where it was implemented into MESS/MAME.
If it was, it didn't change anything as it's still happening. I'm presently running .235. This fix was from 2019, which was many versions before .235.
I have read the links.
It's a lot of information and it looks like the comparison between original and emulated, NTSC vs PAL is constantly mixed in the discussions.
Very confusing but perhaps I have to read it again.
I did try the NTSC test on coco2, dragon32 and dragon 64 from this site :
You can just add it to mame as an autoboot line :
/opt/retropie/emulators/mame/mame dragon64 -autoboot_delay 3 -autoboot_command '10 PMODE4,1:SCREEN 1,1:PCLS1\\\n20 FOR I=0 to 3071:POKE 3072+I,85:NEXT I\\\n30 FOR I=3072 to 6143:POKE 3072+I,170:NEXT I\\\n40 GOTO 40\\\n'
On all machines it produces blue/orange.
Reading the information correct, for PAL, it should produce black and white.
So, at first sight, it seems, the pull request did not fix this.
I did also try the .bas file from "25A - Blending Colors in PAL.VDK" :
Producing these colors on dragon32 seems to work ok.
It also states that programs perform differently between systems.
It makes me wonder, reading the information, if the games are written for NTSC only or for PAL only.
If some NTSC games, running on dragon are in black&white, and on a coco in color, then it would mean that the pull request fix is working.
But it would also means that the test in basic, described earlier, is not a good test or I use the wrong POKE as stated there (are you still with me ?) :
Please note that if you don't have the dos cartridge loaded, you have to change the "POKE 3072," instances to "POKE 1536,".
So I did :
/opt/retropie/emulators/mame/mame dragon64 -autoboot_delay 3 -autoboot_command '10 PMODE4,1:SCREEN 1,1:PCLS1\\\n20 FOR I=0 to 3071:POKE 1536+I,85:NEXT I\\\n30 FOR I=3072 to 6143:POKE 1536+I,170:NEXT I\\\n40 GOTO 40\\\n'
Then I get "gray lines".
It would make sense that you post this into the appropriate forum :
That way people, with more knowledge, can take a look at it.
I just discovered how to make use of an extra help button.
I already knew how to add it but I didn't know how to extract data when pressing it.
I just got it working.
So now it's possible to remove all the HELP lines.
We can now add HELP to each line and select it with the HELP-button.
More text can be added because a full message box is opened.
I also improved the search in the restricted dl part as it had some issues.
And I added a runcommand.log extractor in the restricted dl part.
So if we run a system with mame or lr-mess without BIOS files we can notice in the runcommand.log.
So this information can be simply extracted.
Then we can use this to build up a matching list against the rompack.
So when we run a500 without roms then runcommand will say it misses : a500.7z, a500kbd_us.7z and a2000kbd_us.7z
If it's found in the rompack than the list will be made for these 3 items to get.
Nice feature isn't it ?
It's not yet on github, I will do this when it's more complete with the help.
I found a repository with lua scripts for autobooting.
I did some successful tests.
I forked that repository :
Perhaps we can use this for adding autoboot lines using these lua scripts.
What's nice about it, it can automatically press "tape play" and do a run after loading.
I don't know yet how to write these lua scripts.
So I have to experiment.
Out of my league for sure.. but it looks like a pretty good option if you can get it to work. Remember what we talked about with the DosBox config files.. that would be something similar I imagine where if it sees a specific rom extension, it knows to use a specific load style.
I just did a commit with many improvements :
- Possible to add HELP to each csv line and select it with the HELP-button.
- More HELP text can be added because a full message box is opened.
- Improving the search in the restricted dl part as it had some issues
- added a runcommand.log extractor in the restricted dl part so missing bios roms can be matched with a rompack dl search
- the wget downloads now show a progress bar
- the wget lines are improved with some more options, for example, continue
I did not yet add all HELP parts yet, but I wanted to share this with you, both, first.
Now you both can see what is possible.
I had a few issues with the message-box in above version, that I found later on :
- message-box not centred
- no RetroPie backtitle
- scrolling with page-up/page-down did not work
( and therefore adding more text wasn't an option )
The next update will be fixed for this.
Are you able to make some help texts for the handheld/p&p ?
@folly I've been setting up the Coco3 now using that method of placing the rom in another folder and using the links to point at it.
I found an issue with the auto load command.
using the game Androne and Arena the links named: androne.bin.zip and arena.bin.zip resepectively. It's adding a ".BIN" into the name and using LOAD for both.
Androne is a machine language so it needs the M
It types: LOAD"ANDRONE.BIN", R
It should be: LOADM "ANDRONE" , then EXEC
For BASIC programs it does the same, it adds in the ".BIN" into the name, so it fails. The LOAD statement is correct though as it should just be LOAD "ARENA",R
It's that BASIC and machine language option again...
I did a commit and added loadm:exec lines for coco2/3 .
Let me know if it works.
If the file doesn't have an extension then don't add it in the link, that should work.
Then the link for arena should be called : androne.zip (that works for me using loadm"%basename%":exec)
My arena is a .bas and booted with : arena.bas.zip (using run"%basename%")
Did you had some time to check out the help-button ?
I would like to know what you think of it.
DTEAM last edited by
No, Sorry for that. I'm pretty busy right now. I'll try to check it next week.
No problem !
I had that feeling you were very busy because normally you are very quick.
Next week, will do. ;-)
@folly Hi. Just wanted to check in and let you know the new script for Tandy Coco Floppy is working great.
Just like you said, name needs to be correct for it to work.
It is a lot of work to get the link setup and naming and all that, but once it's running... no issue. It's worth all the trouble to have these games now with a one click option.
Do you know if there is anything I need to add to make the Joystick work? So far, no matter what I do in MESS or the LR core, I can't get any directional response. Does it need a statement like the Apple IIe did?