It is currently Sat Jul 20, 2019 8:29 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 59 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Sun Nov 01, 2015 8:26 am 
Offline

Joined: Mon Apr 01, 2013 11:17 pm
Posts: 437
The x86 architectures has two address spaces: memory and I/O. Everything you've done so far has been in the memory space, which isn't surprising since it's the more commonly used of the two. The one you're looking at now is the I/O address space.

You can only access the I/O space with a few instructions. They are in, out, insb, insw, outsb, and outsw. You'll mostly only want to use in and out for now. Those two instructions haven't changed much in the lifespan of the x86 architecture, so even modern resources can teach you how to use them. (Of course, ignore the parts that reference 32-bit anything, since the V33 is 16-bit.)


Top
 Profile  
 
PostPosted: Sun Nov 01, 2015 9:11 am 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3501
Location: Richmond, Virginia
Wait a minute, I just saw something...

Quote:
Master Control registers:
Word 0: Playfield 1 control
Bit 0x40: 1 = Rowscroll enable, 0 = disable
Bit 0x10: 0 = Playfield enable, 1 = disable
Bit 0x04: 0 = 512 x 512 playfield, 1 = 1024 x 512 playfield
Bits 0x03: Playfield location in VRAM (0, 0x4000, 0x8000, 0xc000)
Word 1: Playfield 2 control (as above)
Word 2: Playfield 3 control (as above)
Word 3: Raster IRQ position.

If a bit has to be 0 to enable BGs, doesn't that mean that they should already be enabled? Unless everything starts out 1 filled.

Edit: Oh, wait, everything does start out 0 filled, so every BG is enabled by default. I just moved graphics into the first tile of BG chr rom.


Top
 Profile  
 
PostPosted: Sun Dec 24, 2017 11:15 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3501
Location: Richmond, Virginia
I somewhat randomly decided to work on this again, this time ignoring sprites and working on everything else first. I've got reading from the controllers to work (not hard, just check different bits in a register) and have also been able to write to the tilemap and change its position and size in vram in addition to changing the palette. My question though, is that while I can successfully change VRAM (where the tilemap is stored) and CGRAM (or whatever it's called here) whenever I want to during active display in MAME, would it be unlikely that this would work on an actual system?

Also, something I noticed is that there doesn't appear to be a brightness register, which means fadeouts have to be done by changing CGRAM. Potentially, you would need to upload 4KB of color data (2048, 15 bit colors) in one frame, and if you can only update CGRAM during VBlank, it may not be possible. Unless you want to have a huge mass of palettes in ROM, you have to make a routine that darkens them as well, which for simplicity, would be subtracting 1 from red, green, and blue at the same time for every color. I imagine modern video games and image processing programs (unless otherwise specified) make bright color elements and overall colors turn darker faster than already dark ones.


Top
 Profile  
 
PostPosted: Mon Dec 25, 2017 4:09 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3697
Location: Indianapolis
I know nothing about this hardware, and little about MAME internally, so hopefully someone else can chime in with better information.

In general though, I would be extremely cautious about using an emulator for testing a new program. This likely would lead to some headaches. Other than not knowing when it's safe to write to video memory, I can imagine other potential situations such as registers or other settings being initialized differently on the hardware, bugs or quirks in the hardware that the developers had work-arounds for (the undesirable side effects might not be emulated, because the situation never arises in the existing games). All that can be overcome, but I'd expect to run into trouble.

The best setup would be to have a ROM emulator plugged into the actual board, but if those 2 devices together cost like $500 or whatever, that's a pretty expensive hobby. If that board happens to run code from a 27C040 EPROM, I could probably loan you a ROM emulator (parallel port device and may require DOS/Win98 though).


Top
 Profile  
 
PostPosted: Tue Dec 26, 2017 12:52 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3501
Location: Richmond, Virginia
Memblers wrote:
I can imagine other potential situations such as registers or other settings being initialized differently on the hardware

Luckily, there aren't to many registers to worry about: http://patpend.net/technical/arcade/m92.html This thing is incredibly straightforward compared to the SNES, but then again, what isn't. :lol:

Memblers wrote:
If that board happens to run code from a 27C040 EPROM

I've been told it runs from a 27C020 EPROM; I have no idea if there's a difference, as they look identical. Well, it uses two and interleaves the bytes, but regardless if your device can support two chips, not even my old Windows XP computer has a parallel port. I just got a bunch of 27C020 EEPROM chips and a EPROM/EEPROM programmer; I have no idea how long it takes to program and reprogram them, but hopefully not long.

Memblers wrote:
but if those 2 devices together cost like $500 or whatever, that's a pretty expensive hobby.

That'll be the cost of the supergun, Sega Genesis to Neo Geo controller converter, SCART cables, SCART to component converter, power supply, EEPROM programmer, EEPROM chips, and the board if I'm lucky. :|


Top
 Profile  
 
PostPosted: Wed Dec 27, 2017 2:31 am 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 696
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
You can forget EPROMs and get some NOR Flash chips instead unless you fancy waiting 45ish minutes each time when erasing EPROMs with your favorite UV eraser. There might be some pinout differences though and you may have to reroute a VPP line to accomodate a new address line, but that you'll find out when comparing datasheets.
020 parts are 2MBit, 040 are 8MBit. 27Cxxx are EPROMs, 28Fxxx and 29Fxxx are NOR Flash. 29L or LV parts are 3.3V and you want to stay away from those.

_________________
http://www.tmeeco.eu


Top
 Profile  
 
PostPosted: Wed Dec 27, 2017 8:56 am 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3501
Location: Richmond, Virginia
Yeah, I found some EEPROMs of the right type that I'll buy instead. I have everything in the eBay shopping cart because I figure I'll order it when I get the boards, but I haven't found a good deal yet. :(


Top
 Profile  
 
PostPosted: Wed Dec 27, 2017 10:46 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3697
Location: Indianapolis
Yeah my ROM emulator is just for one 8-bit ROM, sizes 27C64 through 27C040 (8kB through 512kB). It has a connector to chain multiple devices together to support multiple ROMs, but I only have one of them. And it's pretty obscure so I doubt I'll ever see another one. Was made in 1993, I bought it around '99 or '00 for about $200.

Looks like a pair of these newer ROM emulators would run you $374. Assuming the software allows you connect 2 of them.
http://www.moates.net/ostrich-20-the-new-breed-p-169.html?cPath=95
http://www.moates.net/emuc3206-emulation-cable-32pin-6inch-p-168.html?cPath=32

I'd bet if you watched ebay for a while you could probably find a suitable 16-bit ROM emulator for maybe <$100. Between missing cables, being sold in untested condition, and missing software, it might take some luck and/or improvisation. In my case I had to hand-build a 32-pin adapter (just like the one in the link above, which no one sold at the time), by using a 40-pin one, and sawing it off and epoxying it back together (was around the time I first met kevtris, he helped me with that).

Chip programming speed might take a minute or so, but it depends on the exact programmer and chips used. The EPROM eraser I use at work runs for maybe 15 minutes. On the other hand, SST39SF-series parts erase pretty much instantly. AM29F-series seems to vary widely in program/erase times, but it's still much faster than EPROM. Like TmEE said, I'd also recommend going with NOR flash, such as 39SF. But the pinout is a little bit different, so you would have to mod the the board or build some kind of adapter.

Also when it comes to swapping socketed chips often, what I've done before is buy extra IC sockets (the cheap 'dual-wipe' ones, not the machined pins type). Leave the chip permanently in one of those sockets, then plug that into the other socket on the board. The socket-to-socket connect is like a makeshift ZIF socket, instead of prying it out with a screwdriver. Assuming the 2 socket types are compatible, I've always done it with the exact same type so in other cases, who knows.


Top
 Profile  
 
PostPosted: Sun Mar 17, 2019 2:09 am 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3501
Location: Richmond, Virginia
Old ass thread, but no point in making a third one...

I figured I'd take another stab at this after having programmed learned ARM assembly on a microcontroller and C as well as some C++ (enough to read the M92 driver in MAME, for the most part, anyway). I cleaned up the old code significantly and made a batch file that assembles the .asm file, then copies this and all the other relevant files for the game to a folder, zips it, copies the zip folder to the MAME roms directory, then runs MAME in debug mode; it's been a blessing.

I don't know what I accidentally did while modifying my old code though, because reaching the end of vblank (vblank is where it starts) forces the processor to jump to 0x00000 where the interrupt vector table is (the table should be correct; it's just a bunch of pointers to iret instructions), which obviously results in a crash. It's successfully able to return when I call subroutines though; it looks like "call" only pushes the instruction pointer and not the code segment. I have a GitHub now; I was planning on uploading this whole project when I got something presentable made, but I can do it now if needed.

speaking of which, would it be frowned upon to include free software like 7z as part of the binaries? My script depends on it, for instance.



I did notice something interesting though while looking through the debugger, and that's that clearing the sprite buffer works at least, as something like 4000 cycles are used with a write to 0x9F004. It also changes something called "sprite_buffer_busy" from 0x01 (its value at startup) to 0x00 after clearing the ram. I can't find anything on this, including what address it's located at, even after looking through MAME's sourcecode. I think I know enough x86 assembly now to look through the original game in the debugger and find out how the sprite registers are dealt with, even if the syntax is NEC's.

And having had to look at earlier threads I made on this, wow, thank everyone so much for dealing with me when I first started here.


Top
 Profile  
 
PostPosted: Sun Mar 17, 2019 6:50 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21507
Location: NE Indiana, USA (NTSC)
Drew Sebastino wrote:
I don't know what I accidentally did while modifying my old code though, because reaching the end of vblank (vblank is where it starts) forces the processor to jump to 0x00000 where the interrupt vector table is (the table should be correct; it's just a bunch of pointers to iret instructions), which obviously results in a crash. It's successfully able to return when I call subroutines though; it looks like "call" only pushes the instruction pointer and not the code segment.

I seem to remember there being near call (E8) and far call (9A) instructions in 8086. They'd be analogous to JSR and JSL instructions in 65816.

Drew Sebastino wrote:
speaking of which, would it be frowned upon to include free software like 7z as part of the binaries? My script depends on it, for instance.

In this topic, it was suggested to make a batch file that adds free software to the PATH and then launches Command Prompt. The user would have to customize it based on where each such application is installed.

Drew Sebastino wrote:
I did notice something interesting though while looking through the debugger, and that's that clearing the sprite buffer works at least, as something like 4000 cycles are used with a write to 0x9F004.

Is this some sort of DMA trigger, like $4014 on NES or $FF46 on GB? I seem to remember another platform that put the sprite table in video memory, but just setting its base address caused problems until the program ran a DMA or other copy to VRAM so that the PPU could snoop the writes and cache the sprite table. Maybe it was the Genesis.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Sun Mar 17, 2019 8:43 am 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3501
Location: Richmond, Virginia
It's now on GitHub for anyone who wants to see it: https://github.com/DrewSebastino/irem_m92_starter_kit

tepples wrote:
In this topic, it was suggested to make a batch file that adds free software to the PATH and then launches Command Prompt. The user would have to customize it based on where each such application is installed.

I have no idea how you'd do that; I just included the names of what needs to be downloaded as well as the URLs to each in the readme.

tepples wrote:
Is this some sort of DMA trigger, like $4014 on NES or $FF46 on GB?

Correct. I assume it just zero fills sprite ram rather than copies memory though, as indicated by this: https://patpend.net/technical/arcade/m92.html


Top
 Profile  
 
PostPosted: Sun Mar 17, 2019 4:42 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3501
Location: Richmond, Virginia
I figure this might be useful, somehow:

Attachment:
CPU Registers.png
CPU Registers.png [ 2.29 KiB | Viewed 3568 times ]

These are both the state of the processor one instruction before the interrupt for my program (to the left) and Geo Storm (It actually goes that many cycles before without an interrupt; performing sti triggers it)

Because no one knows NEC's syntax, I'll say what each register is for the ones I know;

IP: IP
SP: SP
F: F
AW: AX
BW: BX
CW: CX
DW: DX
BP: GS (I think?)
IX: SI
IY: DI
DS1: ES
PS: CS
SS: SS
DS0: DS
XA: ???

My interrupt vector table is now 256, 4 byte entries of the exact same address to an iret, so I feel it's safe to rule out the error there...

Also, unrelated, but how would anyone suggest palette conversion? yychr has something called a .pal file, which I see is just 24 bit RGB values. It'd be trivial to write a C program that reduces each color component to 5 bits then bit packs it, but then I'm not sure what I'd do from there. I don't know if it would be overboard if I had my main.asm file include a text (instead of a binary) file that is generated by the converter based on a bunch of different inputted .pal files. It would look like this: (The palette converter now just uses the top 4 nibbles of the palette address, because the bottom is assumed to be 0.)

Code:
section palette1 vstart=0 align=16
PALETTE1   equ (section.palette1.start >> 4)

  dw 0xFFFF,0x0001,0x0002,0x0003,0x0004,0x0005,0x0006,0x0007
  dw 0x0008,0x0009,0x000A,0x000B,0x000C,0x000D,0x000E,0x000F

section palette2 vstart=0 align=16
PALETTE2   equ (section.palette2.start >> 4)

  dw 0xFFFF,0x0001,0x0002,0x0003,0x0004,0x0005,0x0006,0x0007
  dw 0x0008,0x0009,0x000A,0x000B,0x000C,0x000D,0x000E,0x000F


Top
 Profile  
 
PostPosted: Sun Mar 17, 2019 5:44 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8488
Location: Seattle
Drew Sebastino wrote:
XA: ???
Xpansion Address is a V33/V53-specific operation flag that specifies whether the CPU just has the 8086's 20-bit address space literally, or then uses the V series's ridiculous MMU that converts the top 6 address bits of the resulting linear address (after the segment is folded in) into 10 bits (resulting in a 24-bit address space). See section 4 of the µPD70136 datasheet...


Top
 Profile  
 
PostPosted: Sun Mar 17, 2019 7:01 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 940
Code:
  mov ds, [bx + PALETTE_SOURCE]
  mov di, [bx + PALETTE_DESTINATION]

The first line changes ds, in the second line you are still (trying) to use the old ds value to read from memory.

In general, I would always specify the segment register for memory accesses, eg write "ds:[bx+imm]" instead of "[bx+imm]".
One reason is that some opcodes default to use ss instead of ds (if you don't specify ds:).
The other reason for specifying ds is that you will hopefully be more aware of where it is used (and that you shouldn't overwrite ds when still using it in the next instruction).

It is also very important which value you have loaded into ds, in your palette code it's loaded from dx, which points to ram in first loop cylce, and to video hardware in the following loop cycles?

BP is a standard 8086 register. FS and GS are additional segment registers invented on 80386.

Code:
  xor cx, cx
  mov si, cx

That is possible to do that. But you can also write "mov si,0", or "xor si,si" for faster and smaller code.

In interrupt handlers, many systems require to acknowledge the interrupt before returning from the interrupt, I don't know if that's the case here. Best leave interrupts disabled until you get more familar with writing a main program in 8086 code.

For bug searching, I would focus on the program code. The processor state that you have posted isn't so useful, at least not without having a disassembly of the corresponding program code. If you don't have a debugger or disassembler, try to output status messages or change screen color when your program does specific things - then you can see if it's ever reaching that code (or if it has crashed earlier).


Top
 Profile  
 
PostPosted: Sun Mar 17, 2019 8:04 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3501
Location: Richmond, Virginia
nocash wrote:
The first line changes ds, in the second line you are still (trying) to use the old ds value to read from memory.
nocash wrote:
It is also very important which value you have loaded into ds, in your palette code it's loaded from dx, which points to ram in first loop cylce, and to video hardware in the following loop cycles?

Thanks! I had actually found those mistakes by stepping through the debugger when it refused to upload the palette correctly. It's fixed now and uploaded to GitHub. (The readme is also named correctly now) The lack of long addressing is pretty difficult adjusting to...

nocash wrote:
That is possible to do that. But you can also write "mov si,0", or "xor si,si" for faster and smaller code.

Oops, yeah, you're right. I'm definitely still in the process of learning x86.

nocash wrote:
then you can see if it's ever reaching that code (or if it has crashed earlier).

It actually completed that busted palette uploading code and goes to the halt instruction, then jumps to 0x0000. Unfortunately, even after fixing the palette code and stepping through it completely with the debugger, it still gets to the halt and then jumps to 0x0000.

nocash wrote:
In interrupt handlers, many systems require to acknowledge the interrupt before returning from the interrupt, I don't know if that's the case here. Best leave interrupts disabled until you get more familar with writing a main program in 8086 code.

I'd say that sounds like good advice...

lidnariq wrote:
Xpansion Address is a V33/V53-specific operation flag that specifies whether the CPU just has the 8086's 20-bit address space literally, or then uses the V series's ridiculous MMU that converts the top 6 address bits of the resulting linear address (after the segment is folded in) into 10 bits (resulting in a 24-bit address space). See section 4 of the µPD70136 datasheet...

Luckily I shouldn't have to worry about that. I might read it anyway though.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 59 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group