Jump to content

kktos

Members
  • Posts

    50
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

kktos's Achievements

Newbie

Newbie (1/14)

14

Reputation

  1. Nice job, Mr R I like the way you're thinking And I like it also because if we manage to write our own basic, we won't have any licence troubles. And we will have something well suited for the X16. Would you mind starting a thread on your BASIC with some examples, docs... and so on. We may be of assistance Cheers to you, mate !
  2. Thanks guys. Perifractic warned me. Apologies for not having read the rules. And don't get me wrong here. I'm more than willing to help, either in the emulator or in the ROM. Under the supervision of Michael, of course. Have fun, mates
  3. Guys, do you have any plan on when the next release will be out ? Cheers.
  4. Tough crowd Looks like I wasn't good on that one. Doh. Shame on me Anyway, that's an pretty good exercise ! There are things I took for granted thanks for some XP. And I talked about those as if they were obvious. They are not. Obviously. On a personal note, I think I will try to use this exercise in my team while doing code review. Ask the one presenting to explain a concept to others. I learn everyday. And that makes life so interesting. ok, so, now, back to the board to rethink the whole explanation.
  5. Thanks for sharing your thoughts.
  6. oops. Looks like I felt into the web trap. Bruce, my apologies. Laziness is too strong a word to be used here. I shouldn't have use it. Around a beer, talking with you, yes. But not in writing. Again, apologies.
  7. That's the very definition of the developer main trait. :):) So, yes, the API is open. And to each choice, we have PROS and CONS. Either for the sake of readability or for the sake of cycles count. -1- fastcall all in registers, A, X and Y. lda #function_id ldx #<parms ldy #<parms jsr ENTRYPOINT bcc :+ sta error rts :keep_going scrambled: A, X, Y that means you are to manage our registers, save them if needed. And this for ALL our code. Meaning that the cleanup is on us. That's the lazy way from the point of view of the library developer. And quite an annoyance for the developer using it. The call is fast but we will have to manage an overhead on each call. -2- stack call (pascal/c) lda #function_id pha lda #<parms pha lda #<parms pha jsr ENTRYPOINT bcc :+ sta error rts :keep_going scrambled: A Here, the stack is used to pass all parms. The stack cleanup has to be done either by the callee or the caller. -3- "magic" stack call jsr ENTRYPOINT .byte function_id .word parms bcc :+ sta error rts :keep_going scrambled: none like the stack call but using the RTS address as pointer. Very compact and could be applied on any calls. Those are the cleanest ways to do API. The 1 and 2 are the ones used by a lot of compilers, if not all. The 3rd is very ASM oriented. And I only saw this method on 6502. With 6809 and 68K, stack is the way. But we have 2 stack pointers
  8. It was me saying oh no, not again But I'm smiling while writing it down. No worries So you asked a very good question: why ? Good, let's think about it. - list of JMPs -1- (Weak argument) you'll have a 3 bytes * n addresses, bigger than a 2 bytes * n. -2- (Weak argument) you'll have to remember a lot of addresses - vectors table -1- you'll have a single point of entry -2- your API could be very easily consistent and coherent. You can have a stub code dealing with the parms and then calling the internal function. you're making a toolbox rather than a bag of tricks. -3- for the dev, once he gets how to deal with your entrypoint API, job's done. Pretty easy to use. -4- (Weak argument) pretty easy to add, change or remove a function as all calls go thru the stub. About how to pass the parms, it's open. From a dev point of view, I like to call "things" that are not messing with my code. In other words, I have only a few registers on my 6502. please, don't scrambled them. Therefore, I prefer to go towards the parms after the the JSR entrypoint so I'm not using the registers for the call. But there are other ways to do that. The main point here is that I want the call to have the minimalistic impact on my code.
  9. Guys, thanks you very much for this conversation. Very enlightening. I didn't play (yet) on the graphics side of the beast. So pretty informative, your exchange. And I do understand now why I read on another thread a complaint about the intf with the VERA being serial. I saw some systems with a fast and efficient serial intf. No problem. So I was a little surprised by the comment. But I missed something of importance.... if you don't have the aperture, you should have the storage. Hence, I understood now, the wish for more RAM on the VERA. That means we will have ways of improvements for the future next versions And that is a good news.
  10. Oh, No, please, No, not that way !!!! That's too finite, not easily expandable. Prefer a single point of entry and a parameter as function id. Either a LDA #FUNCTION_X JSR ENTRYPOINT or a more versatile: JSR ENTRYPOINT .db function_x .dw parms_ptr
  11. Hum... ok, I got what your saying. And yes, I do agree. I'm merely thinking about Disk Operating System rather that a complete OS.... I'm a apple // fan and as far as I can remember, I always used the computer with a dos. seems to be the minimum GEOS, on the other hand, is a tad too much :):) That's the C64 trying to mimic the Mac with UI and more..... Wrong target.
  12. Oooh. Indeed. Someone was busy Nice piece of software. A little challenging to port to x16.... but could be worth it.
  13. I think I will have to do a proper post here but meanwhile, if you wanna try the slightly enhanced version of the debugger, I've uploaded the binaries. You can also compile it, of course. Here are the windows binaries: Release 20210122 ps: that's the 64bits version so you'll need the 64bits version of SDL2.dll
  14. @paulscottrobsonA straight to the point analysis. And a pretty darn good. My 2cents: I'm seeing a lot of system nowadays using a serial intf and they're pretty efficient. Therefore, I'm not about this being a prob with VERA.... just a feeling here. I may be wrong. Also, the point is to feed the beast with data and let it deal with it. So the more functions VERA has the better Ah... the OS or what is called OS. more a BIOS than a real OS. It has always been the poor child in the C64 realm. But...... we are here to change that ! As developers, we can do whatever we want. So, please, guys, let's do something about it ps: about the BASIC, it's far from the best version..... but then again, this is software. It could be easily changed. Some work to do, yes. For instance, what about the EhBasic. Same background, that is MS, but with some nice features. One being the easiness to extend.
  15. After turning the problem in many ways, I simply realize there is no way for the emulator to use the keyboard without affecting the emulated machine. Pretty obvious afterwards..... Not enough coffee, I presume ;oD Therefore, I did what other emulators are doing, I enhanced the UI to handle buttons.
×
×
  • Create New...

Important Information

Please review our Terms of Use