Yazwho

It is, I asked the same thing a while back as it caught me out as well. The DATA registers are set when the address changes, not on the actual read. When you read, the address changes and thus the register updates. Before the next read if the data at the register changes the register will not reflect the new value. I worked around it like this.

Things have changed since then. VIA is now at $9f00, and the banking is at $00 / $01.

As I said, if you want to be involved, write up the test for where you think there might be a gap, and pop onto Discord. Or post it in the downloads section, apps that can be used in testing (especially edge cases) would always be helpful. However if you're suggesting writing a network debugging app for those who are involved in the development, then no need, as if it was needed it would be done already. There doesn't appear to be any problems with that workflow.

if you want to write testing code, that could be helpful. Create the .prgs and pop into Discord and I'm sure someone with hardware could run it and take a picture.

I think the Mega 65 team did this to help develop while they had very few boards. IIRC their emulators at the time weren't that complete, which is why it was needed. The current emulators do a very good job. There are some slight differences, especially around how each line is rendered, but on the whole for most cases it should be good enough. What edge cases are you looking to explore?

If it's just a vram issue, then ZeroByte suggested a way around it. At the end of the day there are lots of ways to mitigate the issue, but I dont think changing the machine is one of them. This is meant to be a limited machine afterall. There are plenty of people on Discord who can offer suggestions, workarounds, or can just talk about things in a more conversational way than can be done here. Maybe thats worth a go?

You mean coordinating the moving of a lot of sprites on the screen on every frame -- say 1160 of them -- like this?

64 x 64 is very useful though. As would be 128 x 128 and 256 x 256 if there were 1bpp and 2bpp modes available. Vera only has one resolution, 640x480, we use scaling to create 320x240 or indeed any other 'resolution' lower than 640x480.

Someone with more knowledge can correct me: The sizes are so vera can pull data quickly, as it can mask or shift the address to look up the sprite data. At 48bits the maths become more complicated as it would have to calculate the offset first which would reduce the number of sprites per line.

If you don't like cracktros, you can of course buy the game.

Looks like the code above had a little mistake, the Clock was a 32bit integer, which wasn't big enough! The actual number of ticks is $18CE3A5CB, or ~1400Mhz. Almost there, although MASM is a right pain the arse. A project for the future is a general templating took like the 65c02 Bitmagic one!

If only I knew C. I just something that's never really interested me, which was reinforced trying to get the C test harness working for this!

I changed all `pushf` and `popf` and reengineer it using `lahf` and `sahf` which has had a massive effect on performance. I read pushing the flags onto the stack was expensive but I didn't figure it would be this profound! It now runs the same code in 6s. So thats 2,363,729,355 / 6 = 393,954,892 ticks per second, or ~394Mhz. Thats with a test that has plenty of low cycle opcodes that are the more expensive to emulate than the 4 or 5 cycle ones. Good start to the weekend!

First noddy results are in. The code below results (I think) in 2,363,729,355 clock cycles of the 65c02 to complete (ie get to the last stp), on my PC (7700k - 4.2GHz) it takes ~19.5s, this includes a small overhead for compilation and the other bits that VS and .net have for running the emulator. Discounting that, its ~121,216,890 cycles per second. So ~121Mhz? I have no idea if thats good or not? Especially with the overhead that has to be added like interrupt handling and post\pre write address handlers. (Bank switching, etc) lda #$50 sta $02 sta $03 ldy #$ff .mainloop: ldx #$ff .loop: dex bne loop dey bne mainloop lda $02 tax dex txa sta $02 bne mainloop lda $03 tax dex txa sta $03 bne mainloop stp

For sure, but while an emulator is what I'm hoping to achieve, the _aim_ is to learn something new that I've not tried before, namely x64. So it may end up being slower than my C# version. It would suck a bit, but at least lessons would be learnt. Hopefully there will be a bit more logic soon, so I can attempt to benchmark, if its looking poor I can give up and do something else! My current plan is to use something similar to my current C# implementation. Have a frame buffer, and copy that to the graphics card using GL. I think my display code as-is would probably work. The rendering code would be in asm, and tied to the CPU clock. At that point, there are more things to consider when it comes to timing. But right now thats so far in the future, it's not a concern.

In the last week or so its become evident (from Wavicles excellent home made X16 on Discord) how different the official emulator is to the final hardware in terms of the line rendering used by the emulator vs the real hardware. Looking at my first attempt of an X16 emulator it would seem the design would preclude it from ever being able to render like the hardware in real time. So I thought I'd give writing an emulator in x64 assembler, to see if that could improve things. This is not a slight on the official emulator -- its great, and does far more than this project ever will. I just figured it would be a fun personal exercise, including learning x64 assembler. Obviously things are very early; only LDA, LDX, LDY and STA are implemented. However this time I'm writing the unit tests as I go, so compatibility should be assured. My biggest issue has been the tooling, using MASM through Microsoft's C has been quite a pain; and I still can't figure out a way to split the .asm file into separate pieces. (import doesn't seem to do what the docs say it should!) If anyone has and pointers on better ways to write dlls on Windows, please do let me know! I don#t have time or the knowledge to write a x64 compiler like I had to for the 65c02! So what's the point of this post? Not a lot right now, although any help with the point above would be most welcome. Maybe it sparks some ideas, like how a emulator could be used, even if it doesn't emulate the whole machine?

Aye, you need to shift each the layer by the difference of the height of the tile and the height of the graphic using a line interrupt.

For simple isometric playfields I'd use two tile layers, one for each row of tiles. Each tile is a graphic in a diamond shape so they can be linked as you'd imagine an isometric display would be. The layers are then offset by half a tile, so they interlock as below. The green tiles could include imagery that overlaps the red tiles, so you could create some pretty landscapes easily. If you want to get fancy then you can switch the layers using line interrupts on lines that are half way through a tileset. This would mean red tiles can also be above the green. Below are 16x16, but you could of course do 16x8 or 8x8 or use line interrupts for other smaller dimensions, depending on how you want it to look.

I'm on the 'Official Commodore Amiga' discord, which is a good place to ask questions. ( https://discord.gg/MQ6Mfwk ) The 'English Amiga Board' is also a good resource. ( http://eab.abime.net/index.php ) I'm using VSC with the Amiga Assembly extension to compile with vasm and run (+debug) in WinUAE. I have an A500 and 1200, but no small monitor right now, when I pick one up I'll use those for final testing. The copper and the blitter are where I started as well. Both are very interesting to code against. Didn't take long to knock up the app below. (Its animated, so looks a bit better than below!) While the X16 doesn't need such systems, it's a shame it doesn't have them. It makes developing for the system so much more interesting.

I've added code to the image library to take an image and turn it into tiles. Eg, the following code takes logo.png and turns it into 1bpp tiles, and adds a full tile so we know it will be tile #1. (tile #0 is empty and is always added by setting a parameter) public class Logo { private TileData? _tileData = null; public void LoadLogo() { var image = ImageProcessor.Processor.LoadImage(@"logo.png"); // flip pixels for(var i = 0; i < image.Pixels.Count(); i++) image.Pixels = image.Pixels == 0 ? (byte)1 : (byte)0; // add a full set so we know it will be in position #1 var toAdd = new Tile(8, 8, Depth.Bpp_1); for(var x = 0; x < 8; x++) for(var y = 0; y < 8; y++) toAdd.Pixels[x, y] = 1; _tileData = ImageProcessor.Processor.CreateTileMap(image, ImageProcessor.Depth.Bpp_1, ImageProcessor.TileSize.Size_8, ImageProcessor.TileSize.Size_8, false, true, ImageProcessor.TileExcessHandling.Error, new [] { toAdd }); } public IEnumerable<byte> TileMapData() { foreach(var m in _tileData.Map) { yield return m.Index; yield return 0x01; } } public IEnumerable<byte> TileData() { foreach(var tile in _tileData.Tiles) { foreach(var b in tile.Data()) { yield return b; } } } public int Height => _tileData.MapHeight; public int Width => _tileData.MapWidth; } This can then be used: VideoMemory.Copy("tiles", 0x2000, logo.TileData().Count()); and .tileMap: BM.Bytes(logo.TileMapData()); .tiles: BM.Bytes(logo.TileData(), 8); However, I'm going to stop development on the X16 bits while I concentrate on the developing for the Amiga. I'm sure I'll pick this back up at some point, although mostly to generalise the macro compiler to other chipsets -- namely the 68000 -- and to remove the basic X16 emulator to retarget the project in a more general direction.

Nope. I had the wrong text, thanks!

The assembler part now supports embedded procs, and correctly scopes them. (Scopes set with the .scope command still work in the same way.) The end of the proc is also tagged with a constant called 'endproc' if a definition with that name doesn't exist. One thing to note, referencing constants that are defined later in the file will always be assumed to be 16bit, so defined 8 bit ones earlier in the file. This is important for commands like lda to get the right opcode. All of this is demonstrated below: .machine CommanderX16R40; .const a = $01 .proc proca .const a = $02 lda #a ; $02 ;lda #procb:a ; $03 doesn't work yet lda procb:b ; $1234 .proc procb .const a = $03 .const b = $1234 lda #a ; $03 .endproc lda #a ; $02 lda #procb:a ; $03 .endproc lda #a With the output: $0801: $A9, $02 LDA #a $0803:* $AD, $CD, $AB LDA procb:b $0806: $A9, $03 LDA #a $0808: $A9, $02 LDA #a $080A: $A9, $03 LDA #procb:a $080C: $A9, $01 LDA #a Revaluations: $0803: $AD, $34, $12 LDA procb:b and the constants: App:Main:a = $01 App:Main:proca = $801 App:Main:proca:a = $02 App:Main:proca:procb = $806 App:Main:proca:endproc = $80C App:Main:proca:procb:a = $03 App:Main:proca:procb:b = $1234 App:Main:proca:procb:endproc = $808

X4096 View File A new little intro, featuring full frame rate vectors! Original music by cerror. See their other music here: https://modarchive.org/index.php?request=view_profile&query=85822 Thanks! Submitter Yazwho Submitted 04/11/22 Category Demos