Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - PFR_Detect Version 1.00

Reply to topic
Author Message
  • Joined: 18 Sep 1999
  • Posts: 498
  • Location: Portland, Oregon USA
Reply with quote
PFR_Detect Version 1.00
Post Posted: Mon Jan 15, 2001 12:45 am
All-

Version 1.00 of PFR_Detect is now available in the Source Code section.

This version adds backup RAM detection and fixes a bug regarding Page Frame 1.

I'd like to ask those emulator authors who frequent this board to try this new version on their emulators and confirm that the results are accurate. (I.e., if your emulator does not support paging in frame 0, then the test should indicate that region is "FIXED".)

I'd also like to ask those with development cartridges to try running the test on real systems. If possible, please post the results on this messageboard.

Thanks.

--
Eric Quinn
  View user's profile Send private message Visit poster's website
PolestaR
  • Guest
Reply with quote
Post Posted: Thu Jan 18, 2001 1:45 pm
Hi eric, good program. It works fine on my emulator. One thing though, before , your old version didn't work. I traced the problem to me not letting roms <=32k paging themselves into other frames. So I allowed them to, and it worked. Not sure if this can occur on the real SMS, any info from dev cart people would be nice :).
-Jason Starr-
 
  • Joined: 18 Sep 1999
  • Posts: 498
  • Location: Portland, Oregon USA
Reply with quote
Post Posted: Thu Jan 18, 2001 5:00 pm
Quote
> Hi eric, good program. It works fine on my emulator. One thing though, before , your old version didn't work. I traced the problem to me not letting roms <=32k paging themselves into other frames. So I allowed them to, and it worked. Not sure if this can occur on the real SMS, any info from dev cart people would be nice :).
> -Jason Starr-

Thanks Jason. I tried it on your emulator too, of course I wasn't absolutely sure that the results were correct. Thanks for verifying them.

As far as paging 32Kb ROMS goes, the paging hardware for the SMS is in the cartridge it self. So paging is determined by that, not the system. Basically, these means that the design of the cartridge (or card or devcart) will determine how paging is implemented. (Note that this scheme allows the possibility of custom paging, like Code Masters).

--
Eric Quinn
  View user's profile Send private message Visit poster's website
  • Joined: 21 Apr 2000
  • Posts: 598
  • Location: Newcastle upon Tyne, England
Reply with quote
Some problems...
Post Posted: Thu Jan 18, 2001 6:45 pm
Eric,

I tested PFR Detect using my SRAM rewritable development cartridges - 32k, 128k and 256k versions. The 128 and 256k versions are based on the 315-5208 and 315-5235 mappers respectively.

The test platform was a SMS 2 with Japanese BIOS. (For the 128k and 256k tests, I simply quadrupled and octupled the 32k ROM image before writing to the cartridge.)

However, in each case, the program produced a garbled display, as shown below (this is from the 32k test)...



I haven't tried it on the Mega Drive or SMS 1 yet, but will let you know what happens when I do.

Mike
  View user's profile Send private message Visit poster's website
  • Joined: 18 Sep 1999
  • Posts: 498
  • Location: Portland, Oregon USA
Reply with quote
Re: Some problems...
Post Posted: Fri Jan 19, 2001 11:38 pm
Quote
> Eric,

> I tested PFR Detect using my SRAM rewritable development cartridges - 32k, 128k and 256k versions. The 128 and 256k versions are based on the 315-5208 and 315-5235 mappers respectively.

> The test platform was a SMS 2 with Japanese BIOS. (For the 128k and 256k tests, I simply quadrupled and octupled the 32k ROM image before writing to the cartridge.)

> However, in each case, the program produced a garbled display, as shown below (this is from the 32k test)...

>

> I haven't tried it on the Mega Drive or SMS 1 yet, but will let you know what happens when I do.

> Mike

Thanks Mike. I'll look into it this weekend. In the mean time, I have a quick-fix suggestion. If you have the means to re-assemble the test could you try the following?

In the VDPRegistersTable (line 1041) change the first two entries to 0x06 and 0x80 respectively. The line should now read:

.BYTE $06, $80, $ff, $ff, $ff, $ff, $ff, $00, $00, $00, $00

Let me know if this works. Assuming it does, I'll release "official" Version 1.01 soon. Thanks.

--
Eric Quinn
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 25 Oct 1999
  • Posts: 2029
  • Location: Monterey, California
Reply with quote
Re: Some problems...
Post Posted: Sat Jan 20, 2001 12:18 am

Quote
> Thanks Mike. I'll look into it this weekend. In the mean time, I have a quick-fix suggestion. If you have the means to re-assemble the test could you try the following?

> In the VDPRegistersTable (line 1041) change the first two entries to 0x06 and 0x80 respectively. The line should now read:

> .BYTE $06, $80, $ff, $ff, $ff, $ff, $ff, $00, $00, $00, $00

Alternately, you can use a hex editor. At location 2796, change $04 $00 to $06 $80
  View user's profile Send private message Visit poster's website
  • Joined: 21 Apr 2000
  • Posts: 598
  • Location: Newcastle upon Tyne, England
Reply with quote
Re: Some problems...
Post Posted: Sat Jan 20, 2001 2:45 pm
Quote
> > Thanks Mike. I'll look into it this weekend. In the mean time, I have a quick-fix suggestion. If you have the means to re-assemble the test could you try the following?

> > In the VDPRegistersTable (line 1041) change the first two entries to 0x06 and 0x80 respectively. The line should now read:

> > .BYTE $06, $80, $ff, $ff, $ff, $ff, $ff, $00, $00, $00, $00

> Alternately, you can use a hex editor. At location 2796, change $04 $00 to $06 $80


I tried the changes suggested - same result I'm afraid :-(

Mike
  View user's profile Send private message Visit poster's website
  • Joined: 18 Sep 1999
  • Posts: 498
  • Location: Portland, Oregon USA
Reply with quote
Re: Some problems...
Post Posted: Mon Jan 22, 2001 4:53 pm
Quote
> I tried the changes suggested - same result I'm afraid :-(

I've got one more idea about how to fix it. If that doesn't work, I'm at a loss. I'll post it soon.

Can you verify that the dev-cart is being burned correctly?

--
Eric Quinn
  View user's profile Send private message Visit poster's website
  • Joined: 24 Jun 1999
  • Posts: 1732
  • Location: Paris, France
Reply with quote
Re: Some problems...
Post Posted: Mon Jan 22, 2001 6:40 pm
Quote
>> I tried the changes suggested - same result I'm afraid :-(
> I've got one more idea about how to fix it. If that doesn't work, I'm at a loss. I'll post it soon.
> Can you verify that the dev-cart is being burned correctly?

Sorry not having posted on the thread before.
I'll give it a check myself if you can't find a solution before the week-end, so if they're a problem I might be able to do the code/compile/burnt cycle quickly.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 25 Oct 1999
  • Posts: 2029
  • Location: Monterey, California
Reply with quote
A solution?
Post Posted: Mon Jan 22, 2001 9:34 pm
Quote
> Sorry not having posted on the thread before.
> I'll give it a check myself if you can't find a solution before the week-end, so if they're a problem I might be able to do the code/compile/burnt cycle quickly.


I had a look through it, and it seems to me that PrintString gets called without making sure that the VDP isn't actively drawing the screen. The main text of the display works because it's written to VRAM while the screen is off, but the fixed/pageable strings get printed as soon as they checking is finished, which is probably not going to happen during a vblank.

The quickest fix would be to set up a loop at the beginning of PrintString which waits for the top of the vertical blank interval before writing to the screen (not when the screen is off of course).

An interesting thing to note, assuming the problem is in fact as I diagnosed it, is that it seems the VDP will let you set the Address at any time (since the fixed/pageable text always seems to start from the right place, more or less) but won't always let you write to vram. Probably the characters that did go through were output during the horizontal blank.

The are just the sort of little subtle behavior details I'd like to document someday when I get a devcart of my own working.
  View user's profile Send private message Visit poster's website
  • Joined: 18 Sep 1999
  • Posts: 498
  • Location: Portland, Oregon USA
Reply with quote
Re: A solution?
Post Posted: Mon Jan 22, 2001 10:58 pm
Quote
> > Sorry not having posted on the thread before.
> > I'll give it a check myself if you can't find a solution before the week-end, so if they're a problem I might be able to do the code/compile/burnt cycle quickly.

>
> I had a look through it, and it seems to me that PrintString gets called without making sure that the VDP
> isn't actively drawing the screen. The main text of the display works because it's written to VRAM while the
> screen is off, but the fixed/pageable strings get printed as soon as they checking is finished, which is
> probably not going to happen during a vblank.

This thought had occurred to me as well. However, it doesn't explain why printing "TEST COMPLETE" was successful. However, it could just be that in the one case Mike got a screen-shot of it worked. The question, then, is: Across multiple runs of the test, does "TEST COMPLETE" always print correctly?

Quote
> The quickest fix would be to set up a loop at the beginning of PrintString which waits for the top of the
> vertical blank interval before writing to the screen (not when the screen is off of course).

My thoughts, too.

Quote
> An interesting thing to note, assuming the problem is in fact as I diagnosed it, is that it seems the VDP will
> let you set the Address at any time (since the fixed/pageable text always seems to start from the right place,
> more or less) but won't always let you write to vram. Probably the characters that did go through were output
> during the horizontal blank.

> The are just the sort of little subtle behavior details I'd like to document someday when I get a devcart of my
> own working.

--
Eric Quinn
  View user's profile Send private message Visit poster's website
  • Joined: 24 Sep 2013
  • Posts: 141
Reply with quote
Post Posted: Tue Jul 23, 2019 9:06 pm
I think I found a bug when testing on real hardware, PAL Master system, with Alex Kidd BIOS, running from the card slot.

The ROM is loaded on a 32K card, where the range 0x8000 - 0xBFFF is not defined meaning the data lines will be kept floating when reading that range. Probably as a result, the 0x8000 - 0xBFFF range appears as pageable when in fact this card has no paging capabilities at all nor has it any data at all on that range.

Also, the checksum needs fixing otherwise it refuses to boot on my Master System with a BIOS.
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!