New PNUT.EXE loads all 128KB of Hub RAM

cgracey · 2013-06-17 17:43

I modified PNUT.EXE so that it loads all 128KB of Hub RAM and then executes the PASM program at $E80 in Cog 0. Use F11 to load all 128KB RAM, instead of F10 which just loads 2KB at $E80.

It is necessary to space your PASM code to $E80 to step over the ROM area. This is done by starting your program off with:

DAT
    orgh    $E80
    org

<start of PASM code here>

For the DE0-Nano, it will be necessary to start off with 'orgh $18E80' to overcome the 4x memory wrap, due to having only 32KB.

Here's the new PNUT.EXE with example programs for both the DE2-115 and the DE0-Nano:

Prop2Full128k.zip

Note there are two new PASM directives, suggested by Sapieha:

ORGH address - fills hub RAM with $00 bytes up to hub location 'address'
ORGF address - fills cog RAM with $00000000 longs up to cog location 'address'

Sapieha · 2013-06-17 18:18

Hi Chip.

Thanks.

Now You can see that ORGH have be more usable

cgracey wrote: »
I modified PNUT.EXE so that it loads all 128KB of Hub RAM and then executes the PASM program at $E80 in Cog 0.

It is necessary to space your PASM code to $E80 to step over the ROM area. This is done by starting your program off with:
DAT
    byte 0[$E80]
    org

<start of PASM code here>
For the DE0-Nano, it will be necessary to start off with 'byte 0[$18E80]' to overcome the 4x memory wrap, due to having only 32KB.

Here's the new PNUT.EXE with example programs for both the DE2-115 and the DE0-Nano:

Attachment not found.

ozpropdev · 2013-06-17 21:24

Hi Chip.
I have a DE0-Nano board and just tried the new PNUT program with your suggested header of
byte 0[$18E80]
org

This doesn't seem to work. If I remove the suggested line, programs load + run Ok at $E80.
This is using the F10 function in PNUT

Regards

cgracey · 2013-06-17 21:58

ozpropdev wrote: »

Hi Chip.
I have a DE0-Nano board and just tried the new PNUT program with your suggested header of
byte 0[$18E80]
org

This doesn't seem to work. If I remove the suggested line, programs load + run Ok at $E80.
This is using the F10 function in PNUT

Regards

Ooops! I forgot to mention that F10 does the same thing as before. It's F11 that loads the whole memory. Use F11.

Peter Jakacki · 2013-06-17 22:23

cgracey wrote: »
I modified PNUT.EXE so that it loads all 128KB of Hub RAM and then executes the PASM program at $E80 in Cog 0.

It is necessary to space your PASM code to $E80 to step over the ROM area. This is done by starting your program off with:
DAT
    byte 0[$E80]
    org

<start of PASM code here>
For the DE0-Nano, it will be necessary to start off with 'byte 0[$18E80]' to overcome the 4x memory wrap, due to having only 32KB.

Here's the new PNUT.EXE with example programs for both the DE2-115 and the DE0-Nano:

Attachment not found.

Yaaayyy, now I've just got to jump back into the P2 cockpit and hopefully not crash before take-off.

BTW, any chance of getting a dud P2 to check PCB footprints against?, or at least a confirmation on the exact package details in case I've probably missed that.

cgracey · 2013-06-18 00:40

Sapieha wrote: »

Hi Chip.

Thanks.

Now You can see that ORGH have be more usable

Yes, I just implemented your ORGH and ORGF directives. They were needed badly. Thanks for thinking of these.

cgracey · 2013-06-18 00:41

Peter Jakacki wrote: »

Yaaayyy, now I've just got to jump back into the P2 cockpit and hopefully not crash before take-off.

BTW, any chance of getting a dud P2 to check PCB footprints against?, or at least a confirmation on the exact package details in case I've probably missed that.

PM me your shipping address and I think we can send you a few duds.

Sapieha · 2013-06-18 00:55

Hi Chip.

THANKS.

I saw that long time ago -- As fast I started help Cluso with Debugger and tested some code for my Basic

cgracey wrote: »

Yes, I just implemented your ORGH and ORGF directives. They were needed badly. Thanks for thinking of these.

Sapieha · 2013-06-18 01:04

Hi Chip.

Forgot to ask.

How long it is before You post that version with demo's?

cgracey · 2013-06-18 01:20

Sapieha wrote: »

Hi Chip.

Forgot to ask.

How long it is before You post that version with demo's?

The first post in this thread has the latest .zip with PNUT and the demo's.

Sapieha · 2013-06-18 01:24

Hi Chip.

Thanks

Baggers · 2013-06-18 01:53

Thanks for this Chip, I'll look forward to having a play later

Sapieha · 2013-06-18 02:43

Hi Chip.

As You made Start at $E80.

Is it possible to add another start at $1000

cgracey wrote: »

The first post in this thread has the latest .zip with PNUT and the demo's.

Sapieha · 2013-06-18 03:06

Hi Chip.

Now I have tested both OrgH-F directives

Function correctly as expected.

Very much thanks

Sapieha · 2013-06-18 03:24

Hi Chip.

I have be thinking little -- and as always have impossible questions.

It is possible have one START XXXXX directive in PNut that auto-start loaded code from its XXXXX address ??

Sapieha wrote: »

Hi Chip.

As You made Start at $E80.

Is it possible to add another start at $1000

Bill Henning · 2013-06-18 06:49

Thanks Chip!

This will speed up the development cycle of some code I am working on immensely!!!

cgracey wrote: »
I modified PNUT.EXE so that it loads all 128KB of Hub RAM and then executes the PASM program at $E80 in Cog 0. Use F11 to load all 128KB RAM, instead of F10 which just loads 2KB at $E80.

It is necessary to space your PASM code to $E80 to step over the ROM area. This is done by starting your program off with:
DAT
    orgh    $E80
    org

<start of PASM code here>
For the DE0-Nano, it will be necessary to start off with 'orgh $18E80' to overcome the 4x memory wrap, due to having only 32KB.

Here's the new PNUT.EXE with example programs for both the DE2-115 and the DE0-Nano:

Prop2Full128k.zip

Note there are two new PASM directives, suggested by Sapieha:

ORGH address - fills hub RAM with $00 bytes up to hub location 'address'
ORGF address - fills cog RAM with $00000000 longs up to cog location 'address'

potatohead · 2013-06-18 09:28

This is excellent. Thanks for the update chip!

We can specify any address with these right?

Sapieha · 2013-06-18 09:45

Hi potatohead.

As long I have tested -- Any address and as many nested OrgH-F as You need in code

potatohead wrote: »

This is excellent. Thanks for the update chip!

We can specify any address with these right?

David Betz · 2013-06-21 08:33

cgracey wrote: »
I modified PNUT.EXE so that it loads all 128KB of Hub RAM and then executes the PASM program at $E80 in Cog 0. Use F11 to load all 128KB RAM, instead of F10 which just loads 2KB at $E80.

It is necessary to space your PASM code to $E80 to step over the ROM area. This is done by starting your program off with:
DAT
    orgh    $E80
    org

<start of PASM code here>
For the DE0-Nano, it will be necessary to start off with 'orgh $18E80' to overcome the 4x memory wrap, due to having only 32KB.

Here's the new PNUT.EXE with example programs for both the DE2-115 and the DE0-Nano:

Prop2Full128k.zip

Note there are two new PASM directives, suggested by Sapieha:

ORGH address - fills hub RAM with $00 bytes up to hub location 'address'
ORGF address - fills cog RAM with $00000000 longs up to cog location 'address'

Thanks Chip! I suspect this will mostly eliminate the need for p2load but I'll still support it and upgrade it if there is a need.

Sapieha · 2013-06-21 09:16

Hi David.

It don't eliminate p2load YET -- and even if in some cases -- p2load still usable as it have much more Start-up possibility's

And it is always need for stand alone loader..

David Betz wrote: »

Thanks Chip! I suspect this will mostly eliminate the need for p2load but I'll still support it and upgrade it if there is a need.

David Betz · 2013-06-21 09:18

Sapieha wrote: »

Hi David.

It don't eliminate p2load YET -- and even if in some cases -- p2load still usable as it have much more Start-up possibility's

And it is always need for stand alone loader..

I certainly won't eliminate it. I just won't be adding much to it anymore unless someone has a request.

Bill Henning · 2013-06-21 12:37

Actually, p2load has a LOT of features, and I still use it... the new 128k capable pnut does speed up my debug cycle for pasm programs, but does not (easily) let me build large loadables from multiple separate files.

I like both

David Betz wrote: »

Thanks Chip! I suspect this will mostly eliminate the need for p2load but I'll still support it and upgrade it if there is a need.

Cluso99 · 2013-06-22 00:15

Bill Henning wrote: »

Actually, p2load has a LOT of features, and I still use it... the new 128k capable pnut does speed up my debug cycle for pasm programs, but does not (easily) let me build large loadables from multiple separate files.

I like both

Agreed. p2load has multiple file capability. And I like the terminal mode too.

Baggers · 2013-06-22 02:09

Yes I too think P2Load still has a lot of good usage

cgracey · 2013-07-01 13:41

Sapieha wrote: »

Hi Chip.

I have be thinking little -- and as always have impossible questions.

It is possible have one START XXXXX directive in PNut that auto-start loaded code from its XXXXX address ??

I will do something about this. I think if there are no PUB's or PRI's found in the source file, PNUT could operate in a PASM-only mode where a special directive could set the start address. I will add this after I get the Spin2 compiler functioning. Thanks for thinking of this.

David Betz · 2013-07-01 13:46

cgracey wrote: »

I will do something about this. I think if there are no PUB's or PRI's found in the source file, PNUT could operate in a PASM-only mode where a special directive could set the start address. I will add this after I get the Spin2 compiler functioning. Thanks for thinking of this.

How will this start address be encoded into the binary file? For PASM code the binary file is just a dump of memory isn't it? There isn't any header information that could include a start address is there?

cgracey · 2013-07-01 14:06

David Betz wrote: »

How will this start address be encoded into the binary file? For PASM code the binary file is just a dump of memory isn't it? There isn't any header information that could include a start address is there?

I don't know yet, but it could be a long following the 128KB of data.

David Betz · 2013-07-01 15:31

cgracey wrote: »

I don't know yet, but it could be a long following the 128KB of data.

I guess that would essentially be a "trailer" rather than a header. You might be better off with the header though. That way if the image being downloaded was less than 128k you could load only what is necessary. That would speed up loading a bit.

Sapieha · 2013-07-02 05:32

Hi Chip.

Thanks for understanding my intentions on that directive.

Chip I think that even if that directives are found --- It can be good if START XXXXXX can override them and start first INIT code (that in that case will be run and discard and placed at end of other code) for other things TYPE drivers that need be loaded before SPIN and then initialise SPIN interpreter.

cgracey wrote: »

I will do something about this. I think if there are no PUB's or PRI's found in the source file, PNUT could operate in a PASM-only mode where a special directive could set the start address. I will add this after I get the Spin2 compiler functioning. Thanks for thinking of this.

New PNUT.EXE loads all 128KB of Hub RAM

Comments