|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Goto page 1, 2, 3, 4, 5, 6 Next |
Author | Message |
---|---|
|
SMS Test Suite - work in progress homebrew
Posted: Wed Jun 20, 2018 3:20 pm Last edited by sverx on Fri Sep 06, 2019 2:58 pm; edited 1 time in total |
*********************
Latest version can be found here. Current version features quite a number of video tests, audio tests, input tests (SMS and MD pads). Check the last posts in this very thread to see what's new. ********************* Original post with original images follows: Largely inspired by Artemio's 240p, but not a fork of it, yesterday I started writing a test suite for all the stuff regarding our loved machine. So far (version 0.10) I only implemented a few of the basic video tests and the pad test, which is actually my old 'controllers' test integrated into this (still no audio tests are present). I'm open to your suggestions and I need your feedback. ROM is attached. Source will be on GitHub as soon as this reaches version 1.00 |
|
|
Posted: Wed Jun 20, 2018 8:14 pm |
Looks wonderful! :-D | |
|
Posted: Wed Jun 20, 2018 10:46 pm |
I guess for the audio test you can copy Heliophobe's SMS Sound Test, which always had a bug (it writes to the PSG registers every frame instead of only when the values change, which affects the noise channel). Making an equivalent for FM is a whole lot harder. | |
|
Posted: Thu Jun 21, 2018 1:57 am |
Thats pretty awesome, i do like it. Ill have a play with it tonight when i get home.
Having the system region could be handy at the bottom too. Not sure how hard that would be to add. |
|
Revo
|
Posted: Thu Jun 21, 2018 6:04 am |
Would be nice to be able to test some peripheral like Light Phaser, Handle Controller, Paddle Control, Sports Pad, Rapid Fire. | |
|
Posted: Thu Jun 21, 2018 7:18 am Last edited by Maxim on Wed Aug 25, 2021 9:10 am; edited 1 time in total |
One of my project ideas is to make a light phaser program which shows an all white screen, then captures the phaser data for a single frame, then plots that on the screen, and repeats. You should in theory see a half circle pattern drawn with radius depending on the distance from the screen. Emulators will probably look quite different. Then you can experiment with algorithms to determine the centre of the circle - I think some games use (y of min x, x of min y) but I'm sure you could do better. By doing it every second frame, you'd get real-time updates without a full screen flash.
Detecting the other peripherals would be interesting too. I understand that the paddle and sports pad(s) produce quite noisy output so it'd be interesting again to see raw data alongside a smoothed result (paddle games seem to use an exponential moving average by summing the new value to the previous result and dividing by 2). It's getting away from the 240p purposes, but it might be nice to integrate some of the work done in things like http://www.smspower.org/Homebrew/SMSVDPTest-SMS and also to demonstrate some of the VDP differences like tilemap mirroring and sprite doubling limits. |
|
|
Posted: Thu Jun 21, 2018 8:17 am |
@Maxim: for the PSG audio test I was thinking about something simpler like having a small tune played on channel 0 or 1 or 2 or 3 (noise) according to a button press (of course tune on channel 3 would be different). No idea how to test FM.
@wasup: I don't know how region detection works - any hint? @Revo: I'll work on Light Phaser, Handle Controller, Paddle Control, Sports Pad tests too, but probably after version 1.00. Rapid fire can be tested already in Pad Test. If anybody wants to help providing sources (asm and/or C) for other tests - it's welcome (I'm looking at your Light Phaser test, Maxim! ;) ) |
|
|
Posted: Thu Jun 21, 2018 8:21 am |
Theres a bit of info and some sample code for region detection here...
http://www.smspower.org/Development/RegionDetection |
|
|
Posted: Thu Jun 21, 2018 8:30 am |
Ha, I'd write it in assembly I'm afraid! The cognitive load to get going in C may be too much for me.
The SMS test ROM we found plays PSG tones during the button test (while the button is held), which serves to confirm that audio is working at all. |
|
|
Posted: Thu Jun 21, 2018 8:52 am |
Thanks, that works just perfectly! I was wondering anyway if one can have a 50/60Hz mod in a Japanese hardware. Also, how this code behave in a MegaDrive? |
|
|
Posted: Thu Jun 21, 2018 8:53 am |
No problem, I can inline asm quite easily :) |
|
|
Posted: Thu Jun 21, 2018 8:59 am |
Can you even region mod a mega drive for sms compatability mode? Im working on a master system at the moment.. ill have a look at modding a mega drive shortly if you like | |
Revo
|
Posted: Thu Jun 21, 2018 9:06 am |
If you have problems with the Sports Pad, contact Vingazole, he made a little test rom for it few years ago ;) | |
|
Posted: Thu Jun 21, 2018 10:00 am |
I'm reading about the linearity test and I'm a bit puzzled.
I suspect the TV is supposed to show perfectly square pixels both in 50Hz/60Hz modes, right? 256x192 is exactly 4:3... |
|
|
Posted: Thu Jun 21, 2018 10:27 am |
There's borders on the top and bottom of the screen. Pretend that the screen is actually between 224 and 240 pixels tall.
The aspect ratio that the Master System actually displays is somewhat stretched horizontally. Whilst not totally accurate, I pretend that the pixel aspect ratio is around 4 wide/3 tall. Or around 25% wider than it is tall. |
|
|
Posted: Thu Jun 21, 2018 10:57 am |
Ive just done a region and 50/60Hz mod to a megadrive. Your test identifies it as a mega drive and also detects 50/60Hz properly. If i have the region set to JP and run Phantasy star it loads with a MkIII screen first and if the region is EXP it doesnt load with a MkIII screen. So.. looks like it behaves the same on a mega drive. On a game gear it identifies as a master system II, and on a master system 1 it also identifies as a master system II. Not sure if you can actually detect the difference between them in software though. |
|
|
Posted: Thu Jun 21, 2018 11:03 am |
@wasup: SMS II detection is bound to VDP version detection, it checks the sprite zoom bug that was present on the 1st revision thus:
- it's correct that the GG in SMS mode is identified as a SMS II - your SMS could be one of those having a new VDP - if you can run Gemitas properly, it's so - otherwise there's a problem in my detection routine. @Flygon: really??? I thought the pixels were supposed to be almost perfect squares! edit: region detection added - ROM attached |
|
|
Posted: Thu Jun 21, 2018 11:37 am |
Gemitas ran properly so must be a new VDP on mine then.
Have checked the region detection on the mega drive and it worked fine. Great work! |
|
|
Posted: Thu Jun 21, 2018 12:59 pm |
We've seen recently that's not so uncommon, 'new' VDP in 'old' shells - the other way around is instead a rarity.
Thanks for the checks! |
|
|
Posted: Thu Jun 21, 2018 2:03 pm |
My own SMSI uses a newer VDP, itself.
Was somewhat surprised when I found out, in fact!
The pixels start being square when the resolution itself, for 240p machines, is around 320 pixels wide. Naturally, that scales up and down. So 256x240 isn't Square Pixels, but 320x240 is Square Pixels. The Master System's 256x192 mode is just very confusing thanks to the borders it has on the top and the bottom. |
|
|
Posted: Thu Jun 21, 2018 2:20 pm |
The pixels are not square, you can calculate the aspect ratio from the timings - PAL (1.352) and NTSC (1.141). See http://www.smspower.org/forums/11870-PALNTSCBordersAndColor#57854 for timing numbers and http://www.smspower.org/forums/13601-RecordingVideosOfSMSGames#97215 for some mocked up pictures using those aspect ratios. | |
|
Posted: Thu Jun 21, 2018 3:02 pm Last edited by sverx on Fri Jun 22, 2018 11:35 am; edited 1 time in total |
so I guess I need some help to create a proper 256x192 image for the linearity test - two images if ratio is different on PAL/NTSC systems. Any volunteer? :)
then, speaking about SMS revisions, I've been asked if there's a way to detect if the hardware is a SMSII or not, not just the VDP version. I'm not sure it's really needed (I mean, you can see yourself which machine you've got in front of you...) but nonetheless it's intriguing. also, here's a small update - "drop shadow" and "striped sprite" tests added. (attachment removed - we don't want Sonic in there ;) ) |
|
|
Posted: Thu Jun 21, 2018 3:10 pm |
See http://www.smspower.org/Development/WonderBoyInMonsterWorld-SMS for an idea. | |
|
Posted: Thu Jun 21, 2018 6:14 pm |
Could you avoid the dithering on flat areas of the image? Oh, and replace it with Alex Kidd or Opa Opa or similar. That's a post 8 bit Sonic... | |
|
Posted: Thu Jun 21, 2018 8:19 pm |
Sure - sorry I'm not very knowledgeable. | |
|
Posted: Thu Jun 21, 2018 8:49 pm |
I'm no artist - my homebrew can attest to that - but I've been criticised for the same thing in the past. Maybe we can get some help from someone on the forum? | |
|
Posted: Thu Jun 21, 2018 9:48 pm |
SPORTSPAD is just a struct{char x,y;} : // fonctions pour lire les sportspads (trackballs) extern void read_sportspad1(SPORTSPAD * p_sportspad); extern void read_sportspad2(SPORTSPAD * p_sportspad); void read_sportspad_asm() { __asm _read_sportspad1:: ; TRACKBALL #1 ld a,#0x0D ; STROBE 1 LOW (%00001101) ; READ X1 out (#0x3f),a ; ld b,#25 ; wait 80 microseconds 1$: djnz 1$ ; in a,(#0xdc) ; read X1 high nibble and #0x0f ; ( bits 0..3 from port #0xdc) rrca rrca rrca rrca ld d,a ld a,#0x2D ; STROBE 1 HIGH (%00101101) out (#0x3f),a ; ld b,#13 ; wait 40 microseconds 2$: djnz 2$ ; in a,(#0xdc) ; read X1 low nibble and #0x0f ; ( bits 0..3 from port #0xdc) or d neg ld (hl),a ; inc hl ld a,#0x0D ; STROBE 1 LOW (%00001101) ; READ Y1 out (#0x3f),a ; ld b,#13 ; wait 40 microseconds 3$: djnz 3$ ; in a,(#0xdc) ; read Y1 high nibble and #0x0f ; ( bits 0..3 from port #0xdc) rrca rrca rrca rrca ld d,a ld a,#0x2D ; STROBE 1 HIGH (%00101101) out (#0x3f),a ; ld b,#13 ; wait 40 microseconds 4$: djnz 4$ in a,(#0xdc) ; read Y1 low nibble and #0x0f ; ( bits 0..3 from port #0xdc) or d neg ld (hl),a ; ret _read_sportspad2:: ld a,#0x07 ; STROBE 2 LOW (%00000111) ; READ X2 out (#0x3f),a ; ld b,#25 ; wait 80 microseconds 5$: djnz 5$ in a,(#0xdc) ; read X2 high nibble and #0xc0 ; (bits 6,7 from port #0xdc) rrca rrca ld e,a in a,(#0xdd) and #0x03 ; (bits 0,1 from port #0xdd) rrca rrca or e ld d,a ld a,#0x87 ; STROBE 2 HIGH (%10000111) out (#0x3f),a ; ld b,#13 ; wait 40 microseconds 6$: djnz 6$ in a,(#0xdc) ; read X2 low nibble and #0xc0 ; (bits 6,7 from port #0xdc) ld e,a in a,(#0xdd) and #0x03 ; (bits 0,1 from port #0xdd) or e rlca rlca or d neg ld (hl),a ; pad_x2 = -X2 inc hl ld a,#0x07 ; STROBE 2 LOW (%00000111) ; READ Y2 out (#0x3f),a ; ld b,#13 ; wait 40 microseconds 7$: djnz 7$ in a,(#0xdc) ; read Y2 high nibble and #0xc0 ; (bits 6,7 from port #0xdc) rrca rrca ld e,a in a,(#0xdd) and #0x03 ; (bits 0,1 from port #0xdd) rrca rrca or e ld d,a ld a,#0x87 ; STROBE 2 HIGH (%10000111) out (#0x3f),a ; ld b,#13 ; wait 40 microseconds 8$: djnz 8$ in a,(#0xdc) ; read Y2 low nibble and #0xc0 ; (bits 6,7 from port #0xdc) ld e,a in a,(#0xdd) and #0x03 ; (bits 0,1 from port #0xdd) or e rlca rlca or d neg ld (hl),a ; pad_y2 = -Y2 ret __endasm; }
I can't check if this is the good ROM (my phaser is at ichigo's...) : |
|
|
Posted: Thu Jun 21, 2018 10:18 pm |
I always wondered why it didn't work ! I wrote this to test the "periodic noise" : |
|
|
Posted: Fri Jun 22, 2018 4:34 am |
That's awesome! How are you determining 50 Hz vs. 60 Hz and model? I notice some odd behavior on the various system × (optionally) adapter × flash cart combinations I've tried. How should Game Gear be identified? AFAIK no Game Gear actually generates 50 Hz vertical retrace or PAL, yet the tester identifies one of my Game Gears (with a McWill mod) as PAL/EUR/50 Hz when I use EverDrive GG (but NTSC/USA/60 Hz when I use EverDrive SMS!) Stranger still, my other Game Gear (no McWill mod) is identified reliably as NTSC/USA/60 Hz. |
|
|
Posted: Fri Jun 22, 2018 8:04 am |
V-counter is a 8 bit register that counts up to a given number and then 'skips back' (see http://www.smspower.org/Development/ScanlineCounter ) - so I'm discriminating just checking that difference. do {
old_value=VDPVCounterPort; // wait until VCounter 'goes back' } while (old_value<=VDPVCounterPort); if (old_value>=0xE7) TV=PAL; // old value should be 0xF2 else TV=NTSC; // old value should be 0xDA Game Gears aren't identified (yet...?) - if running in SMS mode, they should be identified as SMS II / USA / NTSC, because that's what they will 'emulate'... @vingazole: thanks. I can't test that anyway - would you test that for me please? :) @Bock: wow - that's great. Let see if it actually detects differently than the VDP version, I'll prepare a small test ROM ASAP. edit: @wasup (and others with a 'first version' SMS identified as an SMS II) : could you run the attached small ROM and tell me what values appear on the screen? |
|
|
Posted: Fri Jun 22, 2018 10:43 am |
It shows as SMSII. The menu from my everdrive gets garbled and is left on screen but thats probably not of concern. |
|
|
Posted: Fri Jun 22, 2018 10:45 am |
Thank you for this program. I was very curious to check out the highest frequencies and see how different trackers work: VGM Music Maker: Can't reach the 2 highest frequencies. Deflemask: Somebody more experienced maybe help me with this one? I'm not familiar with the software but what I could work out was that you can reach the highest frequency but not the following 6 frequencies below that. SnevenTracker: You can reach all the frequencies. Sadly the .vgm export of this program is not the best possible, you have to trim the exported file yourself. Those high frequencies are very important for nice PSG cymbal and snare instruments. I feel that the third highest frequency you can reach with VGM MM is just barely enough. I tested my SMS1 with the ModelTest program: VDP rev = [SMSII] Port 0 = [00] I wish I had a SMS1 VDP, I'm curious if there are any differences in sound? I know that MD PSG differs so much from SMS PSG that most of my SMS optimized tracks are pretty much unlistenable on MD. Filtering etc. might be a reason, not sure. |
|
|
Posted: Fri Jun 22, 2018 11:34 am |
@wasup and TomyS:so you both got an SMS I with the new VDP and you both got Port0 = 00! That's nice, I'll run a few tests myself at home this evening and we'll see if we can really identify all the 4 cases:
- 'original' SMS - 'original' SMS with 'new' VDP - SMS II - SMS II with 'old' VDP (very rare!) edit: while we wait, here's a small update. Audio Tests enabled, Sonic replaced with Alex Kidd in shadow/striped sprite tests. |
|
|
Posted: Fri Jun 22, 2018 1:45 pm |
I suspect what we are able to test is the behaviour of the chips - IO and VDP. The mapping to real systems is a bit arbitrary but it may be the case that each combination maps to a unique set of hardware. There's board pictures in the development section, you can search for 315-5124 and 315-5246.
I believe you can tell a Master System from a Game Gear by checking the Z80 for CMOS vs NMOS behaviour for the out (c),0 opcode. Maybe better just to report that as the Z80 type. You can also try swapping in the BIOS ROM and see what's there. Actually, that might be an interesting thing to add - do a little checksum of the BIOS and report if it is a know type. There is different 50/60Hz detection code in games which counts how many times a loop runs between frame interrupts. This will be less sensitive to unusual behaviour in the vcount. |
|
|
Posted: Fri Jun 22, 2018 2:27 pm |
Yes, I'm going to check IO and VDP and try to infer the model from there.
I'm not going to add any detecting of a Game Gear for now, that might become eventually interesting later. But the BIOS checksum might indeed be interesting - do we already have a list of known BIOSes with checksum? As for 50/60Hz detection, I'll keep the current system until proven there are cases where it's not working properly (and Game Gear doesn't yet count ;) ) |
|
|
Posted: Fri Jun 22, 2018 2:41 pm |
Here are the known bioses (with CRC32)
SMS cf4a09ea Alex Kidd in Miracle World [BIOS]/FLAGS=BIOS
SMS 9c5bad91 Alex Kidd in Miracle World [BIOS]/FLAGS=BIOS/COUNTRY=KR SMS 8edf7ac6 Hang On [BIOS]/FLAGS=BIOS SMS 91e93385 Hang On / Safari Hunt [BIOS]/FLAGS=BIOS SMS e79bb689 Missile Defense 3-D [BIOS]/FLAGS=BIOS/EMU_INPUTS=LIGHTPHASER/EMU_3D SMS 81c3476b Sonic The Hedgehog [BIOS]/FLAGS=BIOS SMS 0072ed54 SMS (v1.3) [BIOS]/COUNTRY=US,EU/FLAGS=BIOS SMS b3d854f8 SMS (v2.0) [BIOS]/COUNTRY=EU/FLAGS=BIOS SMS 48d44a13 SMS Japanese (v2.1) [BIOS]/COUNTRY=JP/FLAGS=BIOS SMS 1a15dfcc SMS Prototype (M404) [BIOS]/FLAGS=BIOS SMS 72bec693 SMS Prototype (v1.0) [BIOS]/FLAGS=BIOS SMS ee2c29ba SMS Store Display Unit [BIOS]/EMU_MAPPER=10/COUNTRY=US/FLAGS=BIOS/COMMENT=This is not properly emulated. Doing a SUM of the first a few kb should be more than enough (no need to scan everything). I would suggest display raw tests results (e.g. "VDP test xxxx = 1, IO test 2 = pass etc..") and only after deriving the system from those tests. But having all the raw tests results displayed will help understand what's going on and help with testing on variety of systems. |
|
|
Posted: Fri Jun 22, 2018 2:52 pm |
OK - I can try that. We'll need to create a table with those values (you mean a 16 bit SUM of bytes I believe)
I may add a separate page with all the raw test results, sure. |
|
|
Posted: Fri Jun 22, 2018 4:28 pm |
The Sega checksum is a 16-bit sum. You can spend a bit more time to make it Adler or CRC but there's not much point - we are trying to identify from a known set, not detect bit level changes. | |
|
SG-1000 VDP modes too?
Posted: Fri Jun 22, 2018 6:10 pm
|
Any interest in exercising the SG-1000 VDP graphics modes too, for those systems that have them?
I see someone made a set of color tests for the similar ColecoVision graphics modes and posted them to the AtariAge forums linked from the thread on citrus's new ColecoVision RGB mod (maybe somehow adaptable to SG-1000? really I do not know yet) but so far I have not found anything analogous to the 240p test suite for MSX1, SG-1000, SMS-in-SG 1000 mode, ColecoVision, or TI-99/4A. Obviously these machines (other than SMS) are not really "RGB-native", so some of the tests would have to be fairly different from the more modern true-RGB suites, similar to the situation addressed by the NES/Famicom test suite but of course with a greener palette ;) |
|
|
Posted: Fri Jun 22, 2018 6:49 pm Last edited by bsittler on Fri Jun 22, 2018 11:46 pm; edited 7 times in total |
I think that at least for NTSC the linearity test images here should be effectively identical to the ones from the SNES 240p suite except with the top 16 pixels and bottom 16 pixels cut off edit: n/m, i see that with the truncation measuring distortion becomes impossible, so indeed a new image is needed. edit 2-4: maybe these work better? feel free to use; small circles have radius 1/4th of the large circle edit 5: is PAL SMS really letterboxed that much?!? that usable area is even shorter than 16:9! edit 6: added a couple Game Gear SMS mode linearity tests, but the actual GG pixel aspect ratio is just a guess (need to check this on the real hardware in SMS mode) edit 7: just measured on an actual Game Gear (non-McWill) in GG-SMS subpixel color-bleed mode, SMS pixel aspect ratio is actually around 1.218 ! edit 8: corrected pixel grid alignment edit 9: added a test image with partial compensation for GG-SMS subpixel mapping — this still needs testing on real hardware |
|
|
Posted: Fri Jun 22, 2018 9:27 pm |
I would argue that checking the whole ROM would be wise in case we stumble across new and unknown ROMs; or if the user has a faulty ROM. |
|
|
Posted: Sat Jun 23, 2018 6:02 am |
The goal is to detect what's there (including anything unknown), not to dump it. Checksumming the whole thing would require detecting the size too. | |
|
Posted: Sat Jun 23, 2018 8:23 am |
How do you know a ROM needs dumping unless there's a program out there people can run that could tell them what ROM they have? Surely throwing up a message like "Unknown ROM, please contact us about dumping it!" would help you in the long-run. That said, I can't comment on the practicality and size issue. | |
|
Posted: Sat Jun 23, 2018 8:28 am |
Identifying among known BIOS dump is probably a matter of scanning about 1 KB, then in the event it is useful to dig further, there can be an option for displaying SUM of each 16 KB page + maybe an HEX viewer.
Realistically we don't find BIOS variations that have matching first few KB and the rest is different. |
|
|
Posted: Sat Jun 23, 2018 10:08 am |
...although that could be plausible for a minor patch. The point is, someone running this will be capable of running another program to dump the ROM if necessary.
Do we have useable libraries to write to the Everdrive SD card? I seem to remember the old released source had some FAT code but it has since changed to FAT32, I believe. |
|
|
Posted: Sat Jun 23, 2018 9:47 pm |
we can already write up to 32 KB to SD exploiting the SRAM save feature @bsittler: thanks, I'll try them. Could you please tell me the ratio applied to each one? I want to check if it's the same I expected. |
|
|
Posted: Sat Jun 23, 2018 11:00 pm |
NTSC uses 1.141 PAR from Maxim's comment. PAL uses 1.352 PAR from Maxim's comment. Non-hypothetical GG SMS uses 1.218 PAR from my own measurements. I wouldn't be surprised if this number turns out to be slightly off. Square uses 1.000 PAR. All GG SMS leave left and right 8 pixels blank as they are off-screen on original hardware. Partial subpixel compensation means image was originally generated for SMS-addressable subset of whole-pixel GG screen resolution, then upscaled to corresponding SMS resolution for that region prior to adding 8 pixel borders. In every case I attempted to leave one pixel black borders around the screen edge. Edge widths are not PAR-adjusted, as that would look weirder. Images are mapped to greyscale subset of the SMS palette but have not been adjusted for tile mapping feasibility edit: added images showing how each test image *should* look, more or less (not actually simulating Game Gear original display awfulness, though) |
|
|
Posted: Mon Jun 25, 2018 8:36 am |
mmm... is that info reliable? My small test returns $00 both on wasup and TomyS first revision SMS (both with 'new' VDP) - as expected - but it also returns $00 on my SMS II. unsigned char port0 (void) __naked {
__asm in a,(#0) ld l,a ret __endasm; } should I do anything special before reading port 0 ? @bsittler: thanks, I'm putting them in :) edit: more help needed. Can anyone turn this image to SMS format without using dithering? I seems I can't - colors always turn ugly :( |
|
|
Posted: Mon Jun 25, 2018 4:51 pm Last edited by bsittler on Tue Jun 26, 2018 1:11 am; edited 3 times in total |
Colors do indeed turn ugly. How about one of these? Made with some variations similar to ppmcolors -maxval=3 > sms-palette.ppm ; wget -O- https://uploa
.wikimedia.org/wikipedia/en/e/ec/Alex-Kidd-in-Miracle-World-game-screenshot.png | ngtopnm > akimw-palette.ppm ;wget -O- https://upload.wikimedia.org/wikipedia/en/3/ 0/Alex_Kidd_EnchantedCastle.png | pngtopnm | ppmbrighten -s 20 | ppmquant -mapfile akimw-palette.ppm | pnmscale -xscale 0.7 -yscale 0.8 | ppmquant -mapfile sms-palet e.ppm | pnmtopng > akimw.png or convert Alex_Kidd_EnchantedCastle.png -despeckle -resize '168x
92!' -posterize 4 -despeckle - | anytopnm | ppmquant -mapfile akimw-palette.ppm | pnmremap -mapfile sms-palette.ppm | pnmtopng > akimw2.png |
|
|
Posted: Mon Jun 25, 2018 6:56 pm |
Perhaps it is tied to the VDP type? Or maybe the description is faulty and it would mainly differentiate GG from SMS or possibly MD from SMS? |
|
Goto page 1, 2, 3, 4, 5, 6 Next |