Cybearg Posted September 10, 2014 Share Posted September 10, 2014 Is there any way this could be done, or does the hands-off nature of the kernel make it impossible? If it can be done, how would it be done? Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted September 10, 2014 Share Posted September 10, 2014 If you can access the playfield variables then most likely like how bogax and me did it in the standard kernel: http://atariage.com/forums/topic/218190-smooth-vertical-scrolling-from-data-want-4-way/ 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 10, 2014 Share Posted September 10, 2014 There just isn't enough space to squeeze in horizontal scrolling into the DPC+ ARM code, which is busting at the seams. For very simple playfields you might fake it with the line drawing routines or pushing bytes to the playfield queues, but it will be expensive cyclewise and fairly complex on the bB side of things. It would be nice if the bB DPC+ ARM code could have options you enable and disable like the 6502 kernel, so we could allow the bB coder to pick tradeoffs, but that would mean everybody would need an ARM cross-compiler. Of course, you could always ask the user to rotate the TV 90 degrees. 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted September 10, 2014 Share Posted September 10, 2014 You could keep it real fake by using some of them extra sprites DPC+ allows: http://atariage.com/forums/topic/195843-smooth-horizontal-scrolling-demo/ 2 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted September 10, 2014 Share Posted September 10, 2014 Sounds like you need bB DPC++ I assume the DPC+ bB ARM code lives in bank 0? If so just expand it to also live in bank 1 and only use banks 2-5 for your basic code.For my projects I've only been using bank 5 for 6507 code, the ARM code and the data it uses get all the space in banks 0-4.Hmm, looks like bB is using "human friendly" bank numbers starting with 1 instead of 0 - so give banks 1 and 2 to the ARM code. 1 Quote Link to comment Share on other sites More sharing options...
bogax Posted September 10, 2014 Share Posted September 10, 2014 There just isn't enough space to squeeze in horizontal scrolling into the DPC+ ARM code, which is busting at the seams. For very simple playfields you might fake it with the line drawing routines or pushing bytes to the playfield queues, but it will be expensive cyclewise and fairly complex on the bB side of things. It would be nice if the bB DPC+ ARM code could have options you enable and disable like the 6502 kernel, so we could allow the bB coder to pick tradeoffs, but that would mean everybody would need an ARM cross-compiler. Of course, you could always ask the user to rotate the TV 90 degrees. I have no idea how either the Harmony or the ARM it's self is set up. Can the ARM run from pseudo ROM space in flash? If not can it run from the display queue? Or some piece of RAM that you could copy an auxilliary routine to from ROM. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted September 10, 2014 Author Share Posted September 10, 2014 It would be nice if the bB DPC+ ARM code could have options you enable and disable like the 6502 kernel, so we could allow the bB coder to pick tradeoffs, but that would mean everybody would need an ARM cross-compiler. Is there some reason the ARM compiler can't be bundled with bB so that the ARM compiler is called to do whatever it needs to do during bB's compilation? Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted September 10, 2014 Share Posted September 10, 2014 (edited) Is there some reason the ARM compiler can't be bundled with bB so that the ARM compiler is called to do whatever it needs to do during bB's compilation? I believe the ARM compiler we use, even though it's a free download, is not redistributable - that means we can't take it and bundle it up to give away with something else. Considering the audience for bB, I think adding an additional requirement of requiring you download and install the ARM compiler in order to do DPC+ bB development would be detrimental. Edited September 10, 2014 by SpiceWare 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 10, 2014 Share Posted September 10, 2014 I have no idea how either the Harmony or the ARM it's self is set up. Can the ARM run from pseudo ROM space in flash? It more or less already does. The arm code goes into the first bank, along with the DPC+ kernel. The next logical question is, can it span banks? I don't know the answer to that. It's nearly full now, but whenever I try to push it near the limit, weird effects happen when the kernel runs. I think there's probably some memory structure I'm overwriting when things get too big, or maybe something is crossing a boundary making it inaccessible. Dunno. I never figured that out through my pushing and pulling. [edit] Missed SpiceWare's comment above... yeah, it would be great to expand it into another bank. On the other hand, I'm thinking we may see a bus stuffing DPC++ some time in the future. And completely agreed that including a cross-compiler in bB isn't the right way to do this either. Quote Link to comment Share on other sites More sharing options...
bogax Posted September 10, 2014 Share Posted September 10, 2014 It more or less already does. The arm code goes into the first bank, along with the DPC+ kernel. The next logical question is, can it span banks? I don't know the answer to that. It's nearly full now, but whenever I try to push it near the limit, weird effects happen when the kernel runs. I think there's probably some memory structure I'm overwriting when things get too big, or maybe something is crossing a boundary making it inaccessible. Dunno. I never figured that out through my pushing and pulling. [edit] Missed SpiceWare's comment above... yeah, it would be great to expand it into another bank. On the other hand, I'm thinking we may see a bus stuffing DPC++ some time in the future. And completely agreed that including a cross-compiler in bB isn't the right way to do this either. I was thinking something like having a data statment that contained the ARM code eg scrolling routines and then being able call them from where ever ARM normally runs from. If the bB code ROM space is actually in an external serial ROM or something like that it probably wouldn't work but if the bB code is in the ARMs program ROM space then maybe there'd be no problem. Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 10, 2014 Share Posted September 10, 2014 The bB code space is in ARM addressable memory, so no problem as far as I know. The ARM code would just need to be changed to allow for it. Alternatively, the kernel could also be moved out to another bank (compiler changes required, probably some includes and asm too) which would give the ARM code more space. Or maybe a more formal module format could be put together. In the end I didn't personally want to make these kinds of sweeping decisions for batari's BASIC, since my little 64k fork already went further than I intended. If or when a bus stuffing bB kernel happens, Fred's design will have good deal of DPC+ hindsight incorporated. Quote Link to comment Share on other sites More sharing options...
bogax Posted September 10, 2014 Share Posted September 10, 2014 (edited) The bB code space is in ARM addressable memory, so no problem as far as I know. The ARM code would just need to be changed to allow for it. Alternatively, the kernel could also be moved out to another bank (compiler changes required, probably some includes and asm too) which would give the ARM code more space. Or maybe a more formal module format could be put together. In the end I didn't personally want to make these kinds of sweeping decisions for batari's BASIC, since my little 64k fork already went further than I intended. If or when a bus stuffing bB kernel happens, Fred's design will have good deal of DPC+ hindsight incorporated. Ok I'm assuming that means that the bB code is in the ARM flash ROM program space (and not that there's some external 6507 speed ROM that the ARM can read) So couldn't you put some ARM code in a data stament then define a function 255 call (maybe just a few words?) that calls code in that data statement using the functionality that's already there except for the few words in function 255? edit I recognize that there may be permissions or protections or something that might have to be adjusted, but you wouldn't have to change mappings or move a lot of stuff around or generally rearrange things would you? Edited September 10, 2014 by bogax Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 10, 2014 Share Posted September 10, 2014 So couldn't you put some ARM code in a data stament then define a function 255 call (maybe just a few words?) that calls code in that data statement using the functionality that's already there except for the few words in function 255? You might want to use a different unused number - IIRC the default kernel routine is usually called with function 255 - but yes, conceptually you could call a custom function and pass it the hi+lo byte of the address. The function's only job would be to setup the pointer and goto it. I'm not familiar with ARM assembly, so I'm not sure how relocatable the code is. I'm also not sure if the pages there are marked for execution by default or not. But it all seems doable. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted September 10, 2014 Author Share Posted September 10, 2014 So... are good things being discussed? I really can't gauge from what I've read. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted September 10, 2014 Share Posted September 10, 2014 (edited) On the other hand, I'm thinking we may see a bus stuffing DPC++ some time in the future. I suspect bus stuffing will be called something other than DPC++, it's already confusing enough when DPC+ is used to mean bB DPC+ as opposed to DPC+ bank switching. Is somebody working on a bus stuffing driver? I've done some very preliminary plans, but don't see myself doing anything else with it until after Draconian and Frantic are done. Edited September 11, 2014 by SpiceWare Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 11, 2014 Share Posted September 11, 2014 True enough. There's already enough confusion generated by DPC vs DPC+, let alone DPC+ with custom ARM code, and bB DPC+. I have no idea if someone is working on a bus stuffing driver. I know batari ran a test to see if there was any extra heat generated by the technique some time ago. After that I haven't seen anything else about it... there's a bit of a short list of people who could work on it. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.