JetSetIlly

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.

collect3_cortexm4.bin

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.

I think we have our wires crossed. I've confused things with my suggestion. Sorry.

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). In the case that I found, it has nothing to do with division. TBB is a type of branch instruction.

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.

Good find. So the lesson here is to stick to the original -march and -mcpu options.

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.

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.

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?

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

I agree. Also, it would be nice to come up with a build system that produced both binaries at the same time.

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

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: demo_video.mp4

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.

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.

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

Yes, they should.

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

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.

Yes. They do need to be changed. For example:

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.

collect3_stm32f.bin