Jump to content
IGNORED

Horizontal Scrolling in DPC+?


Cybearg

Recommended Posts

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. ;)

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

 

 

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by SpiceWare
  • Like 1
Link to comment
Share on other sites

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. :ponder:

 

And completely agreed that including a cross-compiler in bB isn't the right way to do this either.

Link to comment
Share on other sites

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. :ponder:

 

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.

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by bogax
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

On the other hand, I'm thinking we may see a bus stuffing DPC++ some time in the future. :ponder:

 

 

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 by SpiceWare
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...