Jump to content
IGNORED

VePseu 99


Gip-Gip

Recommended Posts

5 hours ago, Gip-Gip said:

Apparently I didn't catch this yesterday

 

It should now, the newest binary should at least. It enables 16k mode instead of 4k

 

The 4k mode binary does not work on old hardware, however

Thanks!

 

Just for curiousity's sake, the reason 4k mode doesn't work is that it changes the meanings of the address lines, but the chip still physically has 16k attached. So data doesn't land where you expect.

 

Though in retrospect, I don't understand why that matters on hardware... unless the VDP uses a different circuit to generate the address for display generation than for data access... will need to investigate that at some point. In Classic99 this is definitely the case (a different virtual circuit for pulling video data than for data access). Now that I think it through I'm surprised it didn't work on hardware and need to take a moment to try it out myself. :)

 

Link to comment
Share on other sites

1 hour ago, Tursi said:

Though in retrospect, I don't understand why that matters on hardware... unless the VDP uses a different circuit to generate the address for display generation than for data access... will need to investigate that at some point. In Classic99 this is definitely the case (a different virtual circuit for pulling video data than for data access). Now that I think it through I'm surprised it didn't work on hardware and need to take a moment to try it out myself. :)

 

But you do understand: ? 

 

Link to comment
Share on other sites

1 hour ago, Asmusr said:

But you do understand: ? 

 

Yes, how that's generated I do understand, and I even understood it well enough to confirm that mapping landed data at the expected address in 16k space on hardware.

 

But on a normal memory chip, as long as you read and write using the same address lines, who cares how they are scrambled? ;) So why doesn't it just work anyway? All the tables are located in the first 4k (well, except the sprite descriptor table, but that's empty at startup...)

 

Are we sure it didn't work on hardware? Cause I'm wondering if I should change the Classic99 VDP drawing code to respect the 4k bit too... ;) right now it doesn't and that feels like an oversight.

 

 

 

Link to comment
Share on other sites

2 hours ago, Tursi said:

Are we sure it didn't work on hardware? Cause I'm wondering if I should change the Classic99 VDP drawing code to respect the 4k bit too... ;) right now it doesn't and that feels like an oversight.

 

 

 

I double checked on my TI, definitely didn't work :P

  • Like 1
Link to comment
Share on other sites

Alright! I've somewhat successfully implemented bankswitching! If you want to see a "demo" of this bankswitching, the binary is included down below

 

Not sure how to make a multi-bank RPK sadly

 

The code's kinda half-baked at this point so I'd avoid the GitHub unless you want to be disappointed

 

Next update will be a little more exciting, I promise

vepseu8.bin

Link to comment
Share on other sites

4 hours ago, Tursi said:

Yes, how that's generated I do understand, and I even understood it well enough to confirm that mapping landed data at the expected address in 16k space on hardware.

 

But on a normal memory chip, as long as you read and write using the same address lines, who cares how they are scrambled? ;) So why doesn't it just work anyway? All the tables are located in the first 4k (well, except the sprite descriptor table, but that's empty at startup...)

 

Are we sure it didn't work on hardware? Cause I'm wondering if I should change the Classic99 VDP drawing code to respect the 4k bit too... ;) right now it doesn't and that feels like an oversight.

 

 

 

I'm stumped too. I would have thought it behaves like you said. 

 

On a 16K 4116, there are 7 bits of row and 7 bits of col. A 4K 4027 has 6 bits of row and 6 bits of col. In 4K mode, the 9918 outputs a 0 in the MSB because that's chip enable for the 4027. So if 4116s are connected and 4K mode is active, the 7th and 14th bits of the address are lowered to 0.

 

This would make a pattern of skipping every other 64 bytes of the 16K RAM, and then hitting the bottom half again.

 

Then there is DRAM refresh. If the 9918 is in 4K mode, it doesn't refresh half the rows (because 6 bit row counter.) It does refresh the rows you are using... I don't understand what else might be going on inside the DRAM.

 

There's something weird in the V9938 book too. The appendix tries to explain how to connect 16K chips with 8-bit rows (8,6 not 7,7), so that they refresh, though they lose half the rows.  It seems that they try to guarantee that the MSbit gets toggled, while a LSbit gets ignored. The implication is that it matters.

 

 

 

 

  • Like 1
Link to comment
Share on other sites

18 hours ago, Gip-Gip said:

Not sure how to make a multi-bank RPK sadly

I can do it, but I need to know your banking scheme, i.e. how you switch banks. And is this ROM-only, or do you again use RAM?

 

We have various cartridge types, based on different selector chips (e.g. 74LS378).

Link to comment
Share on other sites

3 hours ago, mizapf said:

I can do it, but I need to know your banking scheme, i.e. how you switch banks. And is this ROM-only, or do you again use RAM?

 

We have various cartridge types, based on different selector chips (e.g. 74LS378).

Both ROM and RAM, using FinalGROM's RAM mode-style bankswitching.

Link to comment
Share on other sites

[Edited] If you are developing directly for the FinalGROM, I'll have to fold at this time. Currently I have no plans for emulating the FinalGROM because it involves a lot of powerful hardware (including a micro controller) that cannot easily be emulated. I could possibly simulate it, though.

 

Maybe it suffices to know how to do the bankswitching and where the RAM is located.

Edited by mizapf
  • Like 1
Link to comment
Share on other sites

4 hours ago, mizapf said:

[Edited] If you are developing directly for the FinalGROM, I'll have to fold at this time. Currently I have no plans for emulating the FinalGROM because it involves a lot of powerful hardware (including a micro controller) that cannot easily be emulated. I could possibly simulate it, though.

 

Maybe it suffices to know how to do the bankswitching and where the RAM is located.

This is from the finalgrom website:

 

Quote

In RAM Mode, each 8 KB bank is split into a ROM half-bank >6000->6FFF and a RAM half-bank >7000->7FFF. The RAM may be freely written to, but it is not battery-backed and will be lost on power down or cart reset. ROM half-banks are switched by writing to >60XX, and RAM half-banks are switched independently by writing to >6800. Intermediate bits are again ignored. Note that writing to >7XXX will not switch banks but update the RAM at that location.

 

Other than that it's a fairly standard bankswitching scheme, write to an even address read-only address in cartridge ROM and a bank is swapped

Link to comment
Share on other sites

1 hour ago, Elia Spallanzani fdt said:

maybe make a little video for those that read this forum on smartphone?

I can provide a mp3. A video wouldn't be much worth anything as it's the same demo level with Wolfenstein music plastered on it

 

Keep in mind the TI's music is fairly loud

vepseu99_5_1_2020.mp3

Edited by Gip-Gip
Link to comment
Share on other sites

I've finally fixed the keyboard! And a few other things

I'm going to work on commenting the code and documenting everything, which will be a pain, but I NEED to do it

 

However I can safely say the testmap is on it's final version for now, and if you want to check it out the binary is attached

 

Tell me how it runs on real hardware too, if you can

vepseu8.bin

Edited by Gip-Gip
  • Like 4
Link to comment
Share on other sites

So far documentation is progressing, easily my least favorite part of development but it's kinda important

 

Quick favor to ask of those who read this, how readable is my commenting? For example, here's the file that loads textures onto the VDP. It's simple, short, and in my opinion, relatively easy to follow. I'd like to opinions on it so I can better document code in the future

Link to comment
Share on other sites

  • 2 weeks later...
1 hour ago, Vorticon said:

Just wondering where progress was on this project.

Currently I'm just working on the game I'm making for this engine. I'm adding features along as I go so once I have a demo out I'll update VePseu99 with the features as well

  • Like 3
Link to comment
Share on other sites

  • 2 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...