Mini demo / tech MD stuff posted by members :)

Jorge Nuno · Post by **Jorge Nuno** » Thu Feb 21, 2008 9:34 pm

I was testing the entire 2 megabyte range:

Clear entire Ram from E00000h to 0, then put a 1 at E00000h

if (*pointer != 0 && pointer == 0)
{
pointer = pointer +2;
Ramcapacity ++;
}
return Ramcapacity;

Pseudo C but it's something like this...

I liked that 256byte chunk idea...

Chilly Willy · Post by **Chilly Willy** » Fri Feb 22, 2008 8:04 am

Stef wrote:
Jorge Nuno wrote:Can you wait for 3 minutes ? Unless you tell me a better way of testing how much RAM is available ...

Also I've just uploaded a new version, it should be a little faster in the initialization...
3mn for RAM checking ???
Can't you just test one byte each 256 bytes of the memory map ?
If you have RAM, you can assume the block size is at least 256 bytes

Most people skip 1K or more at a time. Even on the SEGA, I can see skipping 64K at a time. You won't have less than some multiple of that.

Jorge Nuno · Post by **Jorge Nuno** » Fri Feb 22, 2008 9:36 pm

Done. Now in the current version the available Ram is tested in intervals of 1024 bytes (It can be changed to anything)

Thanks a lot Stef and Chilly Willy for the block suggestion, the program starts a lot faster now

Looking back, 3 minutes is an abuse in terms of a MD program, even a loading of any disc game shouldn't be so lenghty

Chilly Willy · Post by **Chilly Willy** » Sat Feb 23, 2008 9:10 pm

Just remember - you're not TESTING the machine. It's not the program's responsibility to determine if the Genesis is functioning correctly, and checking ALL the memory thoroughly is a diagnostic procedure. Programs can do the least possible to determine things like amount of memory or if a certain feature is present. Now if your program was a diagnostic program, THEN you'd do more.

Jorge Nuno · Post by **Jorge Nuno** » Sat Feb 23, 2008 9:15 pm

No it's just to detect any extra RAM that anyone might add to the console... I might make use of it for some more complicated features

The other hexadecimal value above it it's a real time Heldbuttons status, because Tiido was telling here that some buttons were swapped and others didn't work, so I put it...

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sat Feb 23, 2008 10:58 pm

Stef wrote:
TmEE co.(TM) wrote:Stereo sample player for MD : http://www.hot.ee/tmeeco2/SWAVPLAY.RAR
Does it work on real hardware ? my first attempt worked on emulators but failed with real hardware :-/

Sorry for posting so late, it did work on my MD, but sounded like shit, kind of like in Gens.

And Jorge, this does not work at all on any of my MDs... I waited several minutes, but nothing...

Jorge Nuno · Post by **Jorge Nuno** » Sat Feb 23, 2008 11:02 pm

TmEE co.(TM) wrote:
Stef wrote:
TmEE co.(TM) wrote:Stereo sample player for MD : http://www.hot.ee/tmeeco2/SWAVPLAY.RAR
Does it work on real hardware ? my first attempt worked on emulators but failed with real hardware :-/
Sorry for posting so late, it did work on my MD, but sounded like shit, kind of like in Gens.

And Jorge, this does not work at all on any of my MDs... I waited several minutes, but nothing...

What!? Oh fack! I'm clueless now, I only do RAM test in 1K chunks, it should be up in no time, but but... blaaarghhh!

Did you redownloaded? I'm updating the Bin+Sources everyday...

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sat Feb 23, 2008 11:12 pm

I directly streamed the BIN to my flashcart form the Internet... no go....
(actually re-DLed and flashed

)

Leave the RAM check out.... maybe it works then ?

Jorge Nuno · Post by **Jorge Nuno** » Sat Feb 23, 2008 11:13 pm

Ok I will comment out those lines...

Done: Bin updated

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sat Feb 23, 2008 11:24 pm

No go.... I noticed some VDP reg errors is Kmod.... maybe that has something to do with it ?

Jorge Nuno · Post by **Jorge Nuno** » Sat Feb 23, 2008 11:27 pm

Those are the 2 registers I'm setting up:

First is for digital pixel output, second is for SPA/B pin activation (not sure abou this one), but i've been doing this before the first public release, and it worked before, so they are not the faulty instructions...

Uploaded again (I'm not sure what to modify, whatever)

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sat Feb 23, 2008 11:54 pm

Still nothing.... so damn oddd

8bitwizard · Post by **8bitwizard** » Sun Feb 24, 2008 1:26 pm

Jorge Nuno wrote:No it's just to detect any extra RAM that anyone might add to the console... I might make use of it for some more complicated features

Then you better check for mirroring. If someone adds a 256K byte RAM, but decodes it into an entire 2 megabyte space, your method will see 2 megabytes.

If you write one value to the address in question, and write a different value to a mirrored address, the original value will change. Detecting memory size is more complicated than just keep walking until it stops remembering what you poke into it.

TascoDLX · Post by **TascoDLX** » Sun Feb 24, 2008 1:47 pm

Well...

Code: Select all

CLR.b	$A10009

should be something like...

Code: Select all

MOVE.b #$40, $A10009

and. as long as I'm here...

Code: Select all

Check:		BTST.b	#1,					(a6)
			BEQ.s	Check

is testing the wrong bit. I'll let you figure out what it should be.

Code: Select all

			CLR.w	VDPdata
			BEQ.s	Check

;************************************************
;*                   Paletas                    *
;************************************************

IntroP0:
			dc.w	$0000				;Cor do fundo
			dc.w	$0666				;Cor das letras

Enough with the stunt coding, people!

Jorge Nuno · Post by **Jorge Nuno** » Sun Feb 24, 2008 5:52 pm

8bitwizard wrote:
Jorge Nuno wrote:No it's just to detect any extra RAM that anyone might add to the console... I might make use of it for some more complicated features
Then you better check for mirroring. If someone adds a 256K byte RAM, but decodes it into an entire 2 megabyte space, your method will see 2 megabytes.

If you write one value to the address in question, and write a different value to a mirrored address, the original value will change. Detecting memory size is more complicated than just keep walking until it stops remembering what you poke into it.

My method detects 65536B in the emus, instead of 2MB so I assume it's the way to go

... but I can't test on my MD because my RAMcart isn't ready...

Now a response to TascoDLX:

First that MOVE.b #$40, $A10009, is to put the TH pin in output mode... That's Right!

Next I'm testing the DMA in progress flag:

d15 - Always 0
d14 - Always 0
d13 - Always 1
d12 - Always 1
d11 - Always 0
d10 - Always 1
d9 - FIFO Empty
d8 - FIFO Full
d7 - Vertical interrupt pending
d6 - Sprite overflow on current scan line
d5 - Sprite collision
d4 - Odd frame
d3 - Vertical blanking
d2 - Horizontal blanking
d1 - DMA in progress
d0 - PAL mode flag

But I think it should be a BNE because DMAbusy means bit1 set and then BTST#1 sets the Z flag, if the bit is clear (LOOOL, Deadlock).

That BEQ after a CLR, is a stupid one

, it should be a BRA, but it in the end it's the same... (copy+pasting results in stupid errors like this one)

Updated Source+BIN with Tasco fixes and Ram checker re-enabled.