JetSetIlly
-
Posts
763 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by JetSetIlly
-
-
1 minute ago, Al_Nafuur said:
can you post the binary you have build with the "-mcpu=cortex-m4" flags?
-
1
-
-
Just now, Al_Nafuur said:
Of course there still might be something "wrong" with the binary's custom CDFJ code, but it can't be ARM instructions (otherwise it wouldn't be working in the emulators too).
Agreed. I was really wondering if there was something about the Cortex-M4 architecture that required specific compile flags. Probably not but you never know.
Personally, I would try running a binary on the hardware that has been built with the flags I suggested. If that also doesn't work then we've eliminated a possibility at least.
-
2 minutes ago, Al_Nafuur said:
Just to clarify this:
All test ROMs I have build (by replacing bank 6) from @JetSetIlly's ROM posted here are working as expected in Stella and gopher2600.
I think we have our wires crossed. I've confused things with my suggestion. Sorry.
-
1 minute ago, Al_Nafuur said:
I found the "-mno-thumb-interwork" switch in some of the dcp+ projects.
But as far as I understand the discussion the ARM instructions are also not wanted for the Harmony projects (because the MCU is switched to thumb mode) too.
With ARM instructions our test ROMs shouldn't work in gopher2600 and Stella (but they do!)
The test ROMs we've been building with have used the -mcpu=arm7tdmi -march=armv4t flags. With the -mthumb flag this produces only 16 bit thumb instructions, which are supported by the emulators. For cortex-m4 / armv7e-m, GCC will produce 32-bit thumb instructions, which aren't supported (yet).
1 minute ago, Al_Nafuur said:Also is the collect3 example not using any divisions in "main()" and "Initialize()" which are the functions I am trying to call.
In the case that I found, it has nothing to do with division. TBB is a type of branch instruction.
-
Just now, Thomas Jentzsch said:
I am not sure:
The problem instruction I immediately stumbled on is a Thumb-2 instruction rather than a Thumb instruction.
@Al_Nafuur's observation that the STM32F407 only supports the "Thumb" instruction set is true but after reading a bit further, I see that it actually supports "Thumb-2" instructions, which has 32 bit instructions, like TBB.
The question is whether building with -mcpu=arm7tdmi -march=armv4t will work on the STM32F407. It believe it should but it would be good to ascertain if the alternative flags produce working builds for the PlusCart without any other changes.
If the alternative flags do work then @Al_Nafuur's CALLFN code is correct.
-
Just now, Thomas Jentzsch said:
Here are some excerpts from the discussions I mentioned:
Maybe that helps.
Good find. So the lesson here is to stick to the original -march and -mcpu options.
-
10 minutes ago, Thomas Jentzsch said:
I vaguely remember a discussion regarding the Harmony, that sometimes non-Thumb code was created (especially for math functions IIRC) even though Thumb only was selected. Could this be the case here too?
Maybe when compiling for -mcpu=cortex-m4 and -march=armv7e-m.
This is from the objdump for that binary.
tbb isn't a Thumb instruction.
-
1 minute ago, Al_Nafuur said:
-mthumb
but this should be needed for the emulators too..
14:08:12 **** Build of configuration Default for project Collect_demo **** make custom2 arm-none-eabi-gcc -c -o custom.o src/custom.S arm-none-eabi-gcc -mcpu=arm7tdmi -march=armv4t -mthumb -Wall -ffunction-sections -save-temps -g -Wa,-a,-ad,-alhms=bin/main.lst -Os -c -o main.o main.c arm-none-eabi-gcc -mcpu=arm7tdmi -march=armv4t -mthumb -Wall -ffunction-sections -save-temps -g -Wa,-a,-ad,-alhms=custom.o -Os -o bin/custom2.elf custom.o main.o -T src/custom.boot.lds -nostartfiles -Wl,-Map=bin/custom2.map,--gc-sections arm-none-eabi-objcopy -O binary -S bin/custom2.elf bin/custom2.bin arm-none-eabi-size custom.o main.o bin/custom2.elf text data bss dec hex filename 80 0 0 80 50 custom.o 156 0 0 156 9c main.o 224 0 4 228 e4 bin/custom2.elf 14:08:16 Build Finished. 0 errors, 0 warnings. (took 4s.200ms)Yes. -mthumb just says to produce thumb instructions instead of arm instructions.
You could try -mcpu=cortex-m4 and -march=armv7e-m. That doesn't work on Gopher2600 as is currently stands, but it might be necessary for the hardware.
-
14 minutes ago, Al_Nafuur said:
The STM32F407 only has the Thumb instruction set.
Oh yes. I hadn't noticed that.
Are we 100% sure that the gcc flags, -mcpu=arm7tdmi and -march=armv4t, are okay for the Cortex 4?
-
1
-
-
11 minutes ago, Al_Nafuur said:
but using the bootloader entry point (0x20000808) or the entry point for the custom main function stored at the end of the bootloader (&buffer[0x864]) didn't worked either.
0x20000808 is the start of the Thumb code. The ARM code starts at 0x20000800 - the first two ARM instructions are all about entering Thumb mode.
(In Stella/Gopher2600 we enter at 0x20000808 because neither emulator emulate ARM mode, only Thumb mode. So depending on what your driver is doing you might need to enter at 0x20000800)
11 minutes ago, Al_Nafuur said:So I am not sure if we still have the wrong entry point, a problem with the bootloader, or if something is wrong in the CALLFN area of my code.
What does your driver do when the ARM program has finished? In Gopher2600 I had to be careful about how/when I put the JMP instruction on the bus because of phantom reads.
-
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.
-
3
-
-
2 minutes ago, Thomas Jentzsch said:
I vote for Harmony, just because Stella support for STM32F has not been released yet. And it will probably take some time until it is.
I agree.
Also, it would be nice to come up with a build system that produced both binaries at the same time.
-
3
-
-
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 :: STM32F407VGT6on edit: changes for the .map and objdump file support is in the v0.15.x branch.
-
2
-
-
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.
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:
-
1
-
-
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.
-
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.
-
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:
-
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
-
1
-
2
-
-
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.
-
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.
-
1
-
-
5 minutes ago, Thomas Jentzsch said:
I think some find and replace would work here:
- Replace 0x00... with e.g. xxxx....
- Replace 0x.... with 0x2000
- 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.
-
2 minutes ago, Thomas Jentzsch said:
Well, @JetSetIlly changed them in his Collect3 code.
Yes. They do need to be changed.
For example:
-
1
-
-
2 minutes ago, Thomas Jentzsch said:
I made some progress, but I am stuck at the "defines_from_dasm_for_c.h" file. The ROM and RAM addresses have an offset of 0x00000000, but for STM32F the ROM addresses need an offset of 0x20000000. Does anyone have an idea how to fix that automatically?
I don't think there's a satisfactory why to do that.
You could alter the awk script in the Makefile that generates the defines_from_dasm_for_c.h file so that the offset is added. But that doesn't sound like a good solution to me because it means putting information about the ARM in the 6507 half of the project.
You could have a second awk script I suppose that processes the .h file further but again, that sounds clumsy.
The best solution, and this doesn't really help you here, is to code so that the ROM value (defined in defines_cdfj.h) is added to all memory offsets - even if ROM is 0x0.
-
1 hour ago, Al_Nafuur said:
do you have a build of this version?
The version of collect3 I used is 3 months older, and I am not sure if it is working properly..-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Gopher2600 (continuing development on Github)
in Atari 2600 Programming
Posted
First attempt at a bot capable of playing Space Jockey.
It's very basic but I'm pleased with how I'm doing this. Like the VideoChess bot this is doing "real" monitoring of the screen and "real" joystick control. No reading of RAM or anything like that.