MSX bios interrupthandler

페이지 4/6
1 | 2 | 3 | | 5 | 6

By ro

Scribe (4479)

ro의 아바타

14-03-2014, 11:01

Aaah, ints.. my fave toppic Smile

And I like discussing ideas, not people.. <- that one was meant for you, G. Wink

Disassembling the BIOS is a start. But as GuyveR800 mentioned, the BIOS isn't that pretty. There's only one way to explore the woods; get in and get dirty. Handling INTS can be frustrating. But once discovered, it's a beauty. I've started removing BIOS (or ROM) routines from my code long time ago till the point I totally switched slots to get rid of ROM shizl. It's bloated, slow and mostly useless.

When enabling RAM on page 0 you basically halt your MSX. There's no int interrupt handling, so no keyboard input to give commands. Okay, that should be the first thing to consider: building your own ISR (Interrupt Service Routine), on 38H. Also consider the origin of the interrupt signal. I mainly use the VDP signal, but on music replay routines you could just as good use the timer from the Audio device. If present. See, the VDP is always present. That's your starting point. VDP generates more than one signal, though. Typically the verticalblank (bottom of the screen) and Line interrupt, where the first signal is steady on every 50/60Hz and the second can be programmed to any vertical line, at any point. It's possible to have one vblank and,say, 5 line interrupts. need 5 screensplit? there you go.

And then there's the thing about VDP signal manipulation/monitoring. I'm sure all the tech docs are there, somewhere. TNI has indeed some nice sources.

back in the days, we didn't have no internet. But we figured it all out by doing the deep dive.

have FUN!

By anonymous

incognito ergo sum (116)

anonymous의 아바타

17-09-2020, 22:44

My point here is: disassembling the BIOS is not a practical way to learn more about the MSX system.
Of course you CAN learn from doing that, but you will already need a high level of knowledge to process what you see. If not, you will make the wrong conclusions for sure.

Daemos should not be thinking about putting RAM on page 0... That's all dirty norakomi tactics that lead to huge messes... At TNI we tried so hard to get norakomi to start coding MSX games properly, but he kept stubbornly hanging on to his mess. It really pains me to see Daemos moving in exactly the same direction. Having seen the source code at Nijmegen, I know he's using the exact structure of norakomi projects, and has also copied a lot of terrible hacks from Manbow 2.

I know you people try to be helpful, but what you are IMO doing is screwing up a beginner programmer with information that even an advanced MSX programmer *does not really need to know*.

When learning about the BIOS, you need to know the API, not the exact implementation. Because, like sd_snatcher said in another thread, the BIOS API is *designed* to change in ways that are not obvious, in order to support future hardware differences.

By Grauw

Ascended (10066)

Grauw의 아바타

14-03-2014, 12:32

@ro That works in a vanilla MSX set up, but can cause trouble once people have plugged in peripherals that maybe fires interrupts that it expects to be handled, or install an interrupt handler that expects the ROM to be there. One simple example is that the diskdrive may keep on spinning, which you then have to hack your way around. Also if you NEED the BIOS for certain things, like disk access, you have to go through a lot of troubles to restore things to such an extent that it works again.

Also in general, there is a lot of additional work involved in taking that approach. I used to program in a bare-bones manner like that (though maybe not to that extent), but nowadays I’m actually using the BIOS more and more just because it saves me time, and avoids compatibility issues. You only need to worry about performance in very specific hotspots anyway, so better to save optimisations for those.

@Guyver I see disassembling the BIOS more as a way to gain a better understanding of what the BIOS does. Documentation is fragmented and not always that clear and often missing details. Taking a peek at what’s going on there can be helpful. The ISR is one example that is interesting to take a look at.

Daemos can take input from various sources and form his own opinion. There is not a single truth, no single way to do things. He is not a little lamb that needs to be shepherded to safety.

By anonymous

incognito ergo sum (116)

anonymous의 아바타

14-03-2014, 12:39

Grauw wrote:

Daemos can take input from various sources and form his own opinion. There is not a single truth, no single way to do things. He is not a little lamb that needs to be shepherded to safety.

You don't believe in best practices apparently?

I've already seen too often what happens with programmers that get "help" from MRC. Nobody ever finishes anything over here... Or gets stuck in trivial problems for humongous amounts of time.

I'm not trying to shepherd a lamb, I'm trying to save a promising coder from disaster. If you had seen what I've seen, you would be doing the same.

BTW, I resent the sheep remark, for historic reasons you should be well aware of...

By Grauw

Ascended (10066)

Grauw의 아바타

14-03-2014, 13:07

GuyveR800 wrote:

You don't believe in best practices apparently?

Sure, but there are also reasons to do things differently.

E.g. you can write to the VDP through the BIOS calls, but there are very practical reasons to access it directly. Similarly there are reasons to use the hooks for interrupt handling, or to use IM2.

GuyveR800 wrote:

I'm trying to save a promising coder from disaster.

I don’t even know what to say…

GuyveR800 wrote:

BTW, I resent the sheep remark, for historic reasons you should be well aware of...

I’m not. The only sheep I know is Jorito Smile.

By ro

Scribe (4479)

ro의 아바타

14-03-2014, 13:00

To me the BIOS is cold and ugly. But, when I switch to RAM I do have most important BIOS stuff on the same hooks installed. For example all slot-switching business. I mostly use custom slot-switching combined with the BIOS routines. To get to these BIOS routines I use the interslot-call (24h??) which calls a routine in BIOS. And that's pretty standard stuff which I would believe most devices use. But, that's just a wild guess Smile

Truth be told, in the old days there were not many external devices. so programming without BIOS just worked, always.And you know, I'm that dinosaur coder. So every thing I tell you is from my experience (it 25 years old knowledge). Is it bad to share my experience to the new generation? dunno. perhaps not Smile Maybe it's time for me to upgrade my skills. who knows.

Still, I'd say: screw BIOS and go RAM (but re-use some code)

By Grauw

Ascended (10066)

Grauw의 아바타

14-03-2014, 13:58

ro wrote:

Still, I'd say: screw BIOS and go RAM (but re-use some code)

That’s what I like about DOS Smile.

For me I think an important lesson I learned since programming for the MSX when I was young is, it’s very easy to get hung up in optimising the crap out of everything. It’s a lot of fun, but the products never get finished, and most of it is just wasted effort in the end because it won’t make a perceivable difference to the end user.

By Daemos

Paragon (1952)

Daemos의 아바타

17-09-2020, 22:46

Guyver,

Do absolutely not worry about my coding. There is some history that caused me to use these manbow2 hacks because when I started this, that was the working structure I got suplied with. If it was up to me that day I would have used MSX-DOS2 and other aproaches but that was the working piece of code I received at that moment not knowing about anything but how to type ld a,blablabla. I had to take all of that code for granted and completely reprogramming that ROM will take a few years. Starting with that is not very motivating so yeah then just keeping it that way. Thats how working in a team works. You sometimes just have to take what someone else suplies you and do mind that others have to deal with my wierd creative things as well. You cannot expect people to all do exactly the same. While the basic technique is always the same the variation can be large. We are in fact alive thanks to that Smile I don't find the manbow2 hacks wrong, they are just another way of aproaching the machine. The outcome can go two ways, total disaster, total succes. Manbow2 works.. I have played the game a million times on different machines. Knowning how the source looks like I sometimes wonder why it works but it works.

Now you are affraid from consequences you have seen before then you have not met with my ultra stuborn brains, this project will be finished no matter what happens (well dying is another story). However I do appreciate your advices, concerns and other things you say. I really do. It proves there are people who care not only for their own concern but also for the concern of others and that alone motivates me.

You can read that MRC users are not just doing stuff. I believe most of these advices come from people that carry good knowledge and knowhow in their respective ways. To some we will disagree to some we will agree but in the end all we need is a way most comfortable to ourselfes that can get what we want. Perhaps focusing on my problem as a coder as itself will distract us from the real problems that my code is facing. We must not forget that due to variation we can achieve even more by sometimes trying that what is seemingly impossible.

By Huey

Prophet (2675)

Huey의 아바타

14-03-2014, 13:34

Grauw wrote:
GuyveR800 wrote:

BTW, I resent the sheep remark, for historic reasons you should be well aware of...

I’m not. The only sheep I know is Jorito Smile.

Grauw: Godwin's LAW applies here

By anonymous

incognito ergo sum (116)

anonymous의 아바타

17-09-2020, 22:47

Daemos wrote:

If it was up to me that day I would have used MSX-DOS2 and other aproaches but that was the working piece of code I received at that moment not knowing about anything but how to type ld a,blablabla. I had to take all of that code for granted and completely reprogramming that ROM will take a few years.

Likely, a few days, with setbacks perhaps 2 weeks... It's not actually as much work as you think. It is still a fledgling project, it can go all directions.

Quote:

I don't find the manbow2 hacks wrong, they are just another way of aproaching the machine. The outcome can go two ways, total disaster, total succes. Manbow2 works.. I have played the game a million times on different machines. Knowning how the source looks like I sometimes wonder why it works but it works.

No, it's a wrong approach. TNI *WROTE* that approach, so we are well aware why it is wrong, but norakomi demanded it that way and there was no time to change the whole game. Manbow 2 "works" because TNI made it work. And believe me it "works" less than you think it does.

It can avoid all those problems, but you have to say goodbye to the hacks.

People writing reactions such as Grauw's "I don't even know what to say" from a kind of "oh guyver claims to know better than everyone" need to realize that I *know what the fuck I'm talking about* because I was *deeply involved* with Manbow 2 development, and I have *seen* the code, and the SF2 code and all the other code! I'm not talking out of my ass here.

BUT FINE! It's your life, your choices... I'm not saying "it's my way or the highway", because obviously every project has different needs. The PROBLEM HERE is exactly the "one size fits all" *HACK* that is the Manbow 2 setup!!

페이지 4/6
1 | 2 | 3 | | 5 | 6