Hey, some actual feedback and discussion... I don't know what to do! (-:
Before anyone gets disappointed on Friday, it's looking like this week will only have documentation to serve up. Between researching specs across multiple sources, formatting and rewriting a document and producing testing software, it's taking longer than I would have liked. But it's gotta be done, and I need to make sure that everything in the Tech Scroll is 100% accurate.
As of the time of this post, I've put all my current additions to the Tech Scroll up on the project page. You can review it here:
http://perfectkiosk.net/stsvb1.htmlA fair chunk of the VIP stuff is in there now, so if anyone in the know could take a look at it and let me know what you think, that'd be swell.
Quote:
DaVince wrote:
I'll try to spread the word around as well. :)
Excellent, and thanks! This is gonna be the key to the project's ongoing success.
Quote:
Yeti_dude wrote:
How many iterations of the graphics code have you managed in the past? You know it always takes a few whacks at it.
That'd be approximately zero. However, compared to CPU operations, the VIP is soooooo simple. Just configure some structs in memory and draw a picture with them. It'll take a fair amount of planning to do it right, but I don't see spending more than maybe a day on that.
Quote:
Yeti_dude wrote:
As you're rewriting the VIP portion of the tech scroll, make sure to switch over to KR155E and community's terminology.
Once again, I really want to stress that this isn't "the community's" terminology, but Nintendo's, and that's the only reason I'm using it. I don't like certain things about it (use of the word "world" makes no sense, something named DPSTTS surely isn't called "Display Control Read Register", etc.), but it all needs to be as official as possible to be done correctly.
Quote:
Yeti_dude wrote:
[Regarding the VIP debugger window] Guy, you can do it! This would be a huge boon to VBDE and it's sprite engine.
Could you elaborate on why you feel this would be so helpful? I'm interested to know the thought processes of other developers. I've generally been able to visualize my graphics when doing my own software, but I'm not the best case study.
Quote:
Yeti_dude wrote:
I know it's blasphemy, but it wouldn't even be the end of the world if the column table wasn't fully emulated. Like, what good is it anyways?
For the sake of accuracy I'd like to implement it eventually, but it's a rare case a game system being able to modify not just pixel colors, but pixel dimensions as well. I'm not especially worried about it right now, since I don't know of any software that ever changes the column widths.
Quote:
Yeti_dude wrote:
Let's see if you can get graphics emulated within a week AND then a home-brew demo! Next step looks like VSU, and then busses?
The software I'm using to research the VIP is extremely basic and not worthy of release. It's literally just this:
Enough to get the information I need, but not fancy by any stretch of the imagination. The only reason VSU Workshop and CPU Workshop came into being was because I needed comprehensive control over those subsystems and it made sense to make them presentable. So I'm sorry to say, no VIP Workshop this time. (-:
The memory bus was the first thing I implemented, since the CPU requires it for fetching instructions and loads/stores. The source file vue/JavaVUE.java contains generic implementations for read and write methods, which the CPU module uses during its internal operations. Those methods are responsible for routing accesses to the appropriate hardware components, and adding, for instance, VIP support is a simple matter of just putting a line in there to tell it where to forward the access request.
Next step is probably going to be the game pad. I'd like to see things operating sooner than later. (-:
Quote:
Yeti_dude wrote:
What if the PC emulator could make copies of raw rom & ram data: graphics, instructions, registers and interrupt routines? Let the user edit the code or graphics and then save out a usable home-brew resource.
I've considered a "Save ROM" command since the debugger window will eventually have assembler functionality, but beyond that it's a tricky matter to automatically re-pack things like graphics data back into a ROM image. But don't let the dream die here! Keep the ideas coming, because this
is a community effort after all!
Attach file:
vip_testing.png (0.42 KB)
USA
Netherlands
![Open in new window](javascript:CaricaFoto("https://www.planetvb.com/uploads/newbb/3060_5af367ac8f439.png");)
