CDFJ support?

[Thomas Jentzsch]

1 minute ago, Al_Nafuur said:

I don't think it should be done this way. I think using defined ROM/RAM base addresses will make it easier to switch between a STM32 and LPC200 build for the developer.

Agreed. But then this has to be done by the developer.

[JetSetIlly]

5 minutes ago, Thomas Jentzsch said:

I think some find and replace would work here:

1. Replace 0x00... with e.g. xxxx....
2. Replace 0x.... with 0x2000
3. Replace xxxx with 0x00

But I don't know command line tools which could be integrated into the makefile.

 

It sounds dangerous to me.

 

The awk script processes the DASM symbols file. Some are offsets into flash and some are just numeric values. The script could be altered so that 0x2000000 is ORed with the value in the symbols file but that would alter the non-address values too.

 

If you change line 63 of the Makefile to

 

      awk '$$0 ~ /^_/ {printf "#define %-25s 0x2000%s\n", $$1, $$2}' $(PROJECT).sym >> main/$(DASM_TO_C)

 

Then that *might* work. But as I say, that changes all values not just the ones you want.

 

I've not looked at Andrew's code yet but I would start searching for references to those symbols in the C code and have a think about whether they are memory accesses or not. If they are then add the ROM value.

 

 

[Thomas Jentzsch]

20 minutes ago, JetSetIlly said:

I would start searching for references to those symbols in the C code and have a think about whether they are memory accesses or not. If they are then add the ROM value.

Yup, that's what I meant above.  

[JetSetIlly]

Just now, Thomas Jentzsch said:

Yup, that's what I meant above.  

 

I think we're just going to have to accept that this is good practice and we need to do that going forward.

 

 

 

[Thomas Jentzsch]

Attached are the common files I changed (just a quick hack). IMO these should be provided and maintained from the UnoCart/PlusCart groups. And of course the CDF(J) etc. schemes have to implemented first.

custom.boot.lds custom.S

defines_cdfj.h

Edited December 8, 2021 by Thomas Jentzsch

[+Al_Nafuur]

24 minutes ago, Thomas Jentzsch said:

Attached are the common files I changed (just a quick hack). IMO these should be provided and maintained from the UnoCart/PlusCart groups. And of course the CDF(J) etc. schemes have to implemented first.

defines_cdfj.h 5.84 kB · 3 downloads custom.boot.lds 1.73 kB · 1 download custom.S 1.56 kB · 1 download

I am not sure, but I think in defines_cdfj.h lines 70, 83, 95 and 122 need a "ROM_BASE +" prefix for the value too.

 

[JetSetIlly]

2 minutes ago, Al_Nafuur said:

I am not sure, but I think in defines_cdfj.h lines 70, 83, 95 and 122 need a "ROM_BASE +" prefix for the value too.

 

 

Yes, they should.

[Thomas Jentzsch]

Updated. Thanks!

[+Andrew Davie]

@Thomas Jentzsch what do these files mean for Cubiks?  Other than dropping them in and compiling, what else needs to change for it to work on PlusCart? 

[Thomas Jentzsch]

In your own code, whenever you are accessing ROM you have to make sure that you use the correct offset. Also for defines coming from DASM.

 

With Harmony this is offset 0x00000000, so it might not be easy to identify. 

Edited December 8, 2021 by Thomas Jentzsch

[+Al_Nafuur]

32 minutes ago, Andrew Davie said:

@Thomas Jentzsch what do these files mean for Cubiks?  Other than dropping them in and compiling, what else needs to change for it to work on PlusCart? 

 

25 minutes ago, Thomas Jentzsch said:

In your own code, whenever you are accessing ROM you have to make sure that you use the correct offset. Also for defines coming from DASM.

 

With Harmony this is offset 0x00000000, so it might not be easy to identify. 

 

some of the functions defined in "defines_cdfj.h" take the offset :

 

• setPointer

• setPointerFrac

• setIncrement

• setIncrement2

• ...

which means you shouldn't change the parameter when calling.

 

and some of them take the absolute value (mostly the MemCopy and MemSet ones) :

• myMemset

• myMemcpy

• myMemsetInt

• ...

 

which means you must prefix the parameter with "RAM_BASE +" (I don't think they are called with the ROM pointers), when you are using the defines from "defines_from_dasm_for_c.h"

 

Edited December 8, 2021 by Al_Nafuur
add defines_from_dasm_for_c.h

[+Andrew Davie]

31 minutes ago, Thomas Jentzsch said:

In your own code, whenever you are accessing ROM you have to make sure that you use the correct offset. Also for defines coming from DASM.

 

With Harmony this is offset 0x00000000, so it might not be easy to identify. 

Still confused. The following is ROM access, if table is a const array....

	int example = table[0];

Are you saying this needs to be modified to account for ROM offsets?

 

[Thomas Jentzsch]

Depends on the address of "table". If the address is already considering the ROM base address, then not.

[+Al_Nafuur]

2 minutes ago, Andrew Davie said:

Still confused. The following is ROM access, if table is a const array....

	int example = table[0];

Are you saying this needs to be modified to account for ROM offsets?

 

if "table" is one of your own const arrays in your c code, then you don't need to change it, because the compiler handled it according to the memory definitions in "custom.boot.lds"

 

 

[+MarcoJ]

It would be super, super cool to support CDFJ. The icing on the cake of an already incredible product.

[JetSetIlly]

This might help track down problem code when converting to the PlusCart.

 

In the video below, I'm running https://github.com/JetSetIlly/plusromtest_cdfj but without the fixes in main.c.

 

 

So, illegal accesses are looked up in the compiler's map file and illegal memory accesses and the function name are printed to the log.

 

I should be able to get more detail in there - it will mean changing the compiler options so that a detailed listing is produced but it would be worth it I think. In the meantime, this at least gives the programmer a clue as to where to begin.

 

Code pushed to:

 

https://github.com/JetSetIlly/Gopher2600/tree/v0.15.x

  

 

[JetSetIlly]

19 hours ago, JetSetIlly said:

I should be able to get more detail in there - it will mean changing the compiler options so that a detailed listing is produced but it would be worth it I think. In the meantime, this at least gives the programmer a clue as to where to begin.

 

I've come to an impasse with this. I would expect that compiling with the -g option would put the necessary debugging information into armcode.elf. However "objdump -S" produces incomplete interleaving of the Source Code. For example:

 

 

Any GCC for ARM experts around who might now what the missing ingredient is?

 

on edit: So it's identified the function blocks but not what's in the function. Compare to a C program that does objdump correctly:

 

Edited December 9, 2021 by JetSetIlly

[Thomas Jentzsch]

Stupid question: What is incomplete here?

[JetSetIlly]

12 minutes ago, Thomas Jentzsch said:

Stupid question: What is incomplete here?

After compiling with the -g option, running objdump -S on the resulting elf binary should output the disassembly (including the bytecode).

 

The disassembly should be commented with the source code that is responsible for the assembly. We can then use this file to produce more useful debugging information - for example, if there is an illegal access at PC 0x2000093c, we can say that this happened in SpashOverScan() function and give the exact line number in the source file.

 

However, in this instance, the detailed source code information doesn't seem to be included in the compiled object.

Edited December 9, 2021 by JetSetIlly

[+Andrew Davie]

1 hour ago, JetSetIlly said:

After compiling with the -g option, running objdump -S on the resulting elf binary should output the disassembly (including the bytecode).

 

The disassembly should be commented with the source code that is responsible for the assembly. We can then use this file to produce more useful debugging information - for example, if there is an illegal access at PC 0x2000093c, we can say that this happened in SpashOverScan() function and give the exact line number in the source file.

 

However, in this instance, the detailed source code information doesn't seem to be included in the compiled object.

Could it be that optimisation is interfering with the alignment?

I believe optimisation is a subsequent pass, which will destroy the associations to source lines.

 

[JetSetIlly]

19 minutes ago, Andrew Davie said:

Could it be that optimisation is interfering with the alignment?

 

It's a good thought but I don't believe optimisation is the cause of this. The source information should still be present, although it might be misleading due to the optimisations.

 

For comparison, a regular C program (for Intel CPUs) compiled with gcc when compiled with -Os, will retain the debugging information.

 

Also, compiling with -Og, which is an optimisation level specifically for debugging, doesn't work either.

 

Edited December 9, 2021 by JetSetIlly

[JetSetIlly]

Cracked it. I was putting the -g option in the wrong place on the command line ?

 

Example makefile in my plusromtest_cdfj github. See the diff for what I have changed.

 

https://github.com/JetSetIlly/plusromtest_cdfj/commit/b2a8baf0c07656e11a112144ed5b8ef0c610f6f2#diff-76ed074a9305c04054cdebb9e9aad2d818052b07091de1f20cad0bbac34ffb52

 

Running Gopher2600 will now print the source code relating to the access error. No line numbers yet - I'll have to investigate that further. But even in the current state, I think this will be very useful.

 

 

And a video:

 

 

 

[Thomas Jentzsch]

Got Cubix running in Stella using STM32F addresses. I did not change Andrew's code at all, just used the attached fixed files.

 

It doesn't work in gopher2600 though. So one of the emulators must be wrong.  

cubiks.bin

defines_cdfj.h custom.boot.lds custom.S

Edited December 9, 2021 by Thomas Jentzsch

[JetSetIlly]

1 hour ago, Thomas Jentzsch said:

Got Cubix running in Stella using STM32F addresses. I did not change Andrew's code at all, just used the attached fixed files.

 

It doesn't work in gopher2600 though. So one of the emulators must be wrong.  

cubiks.bin 32 kB · 2 downloads

defines_cdfj.h 5.89 kB · 0 downloads custom.boot.lds 1.67 kB · 0 downloads custom.S 1.59 kB · 0 downloads

 

Nice work.

 

It's fine in Gopher2600. The preferences file needs to be manually changed to:

 

hardware.arm7.model :: STM32F407VGT6

 

on edit: changes for the .map and objdump file support is in the v0.15.x branch.

 

https://github.com/JetSetIlly/Gopher2600/tree/v0.15.x

Edited December 9, 2021 by JetSetIlly

[JetSetIlly]

One thing we still need to figure out is how the STMF32 differs to the LPC2000 internally. We now understand the memory model differences I believe, but there are still questions about the timer and whether there is a MAM and/or how it works in the STMF32.

 

In the meantime, I believe we can auto-detect differences between the memory models quite easily.

 

Auto-detection of what model a CDF binary is targetting can be done through inspection of 0x863 and 0x867:

        if data[0x863]&0x20 == 0x20 && data[0x867]&0x20 == 0x20 {
            memModel = memorymodel.PlusCart
        } else {
            memModel = memorymodel.Harmony
        }

 

And similarly for DPC+ the differences are in 0xc4b and 0xc4f:

        if data[0xc4b]&0x20 == 0x20 && data[0xc4f] == 0x20 {
            memModel = memorymodel.PlusCart
        } else {
            memModel = memorymodel.Harmony
        }

 

There are other differences but these are the ones I'm using.

 

Edited December 12, 2021 by JetSetIlly