Real life has a nasty habit of unravelling the best-laid of plans, and the last couple of weeks have seen me with very little time to spend on the project - but I have done a little as the opportunity has arisen, so as promised here's a screenshot of what the IDE looks like right now. It's not as far along as I would have liked, but it's getting there - and there's another panel (the memory-dump view) which is nearing completion but not shown, so progress is slow but steady:
As you can see, we have a disassembly panel (which does what it says on the tin) and an address select/convert tool which lets me convert addresses from Hex to Decimal (and back) and also makes use of the annotation labels (if present) to find and select addresses by name. There's a little more I want to do to this tool, but it works so far.
In the meantime, when I've not been actively coding, I've been mulling-over the second version of the core, which emulates the 6502 at the T-state level. I've got a reasonable idea of how to make it work, so once I've got the IDE where I want it, I'll be in a position where I can instantiate both the current V1 core and the new V2 core side-by-side, and watch the behaviour of each simultaneously as they step through instructions. Which should be cool. :)
In the meantime, when I've not been actively coding, I've been mulling-over the second version of the core, which emulates the 6502 at the T-state level. I've got a reasonable idea of how to make it work, so once I've got the IDE where I want it, I'll be in a position where I can instantiate both the current V1 core and the new V2 core side-by-side, and watch the behaviour of each simultaneously as they step through instructions. Which should be cool. :)
Posts
3 comments:
Nice work! Where did you get the annotation labels or did you just put together some by yourself?
Blimey, I thought this blog had sunk without trace, as no-one was looking at it (which is why I stopped updating it)!
To answer the question, the annotation labels are the result of a laborious chunk of work merging (I seem to recall) three different VIC-20 memory-map datasets, and massaging them into something that fits into the emulator .MAP file schema where the machine in which the CPU is executing is defined.
There's still work to do in cleaning-up the labels, as the free-form layout of the original sources often meant odd characters or repeated words got left in. However, I've ended-up with a reasonably good annotation for just about every memory location in the VIC-20 RAM, and a sensible name for every ROM routine and vector.
If you want to have a stab at it yourself, just google for VIC-20 memory map annotation, or I could even send you the raw Excel spreadsheets and/or the .MAP file for you to play with...
I found your blog via Miggy which is fortunate. A couple of months ago I decided to start writing a Vic-20 emulator in Java. First, because I already wrote one in MSVC++ ages ago and lost the source code. Second, because I want to work on my Java skills and it may be possible that modern computers are fast enough for 8-bit CPU emulation in Java.
Your project is quite interesting, because I want to make the emulator cycle exact, a goal from which I am still miles away. First I have to improve execution speed ...
Another goal is a decent debugger. Because of the lack of comprehensive symbol tables, I considered analysing code for code and data sections and extract labels for jump targets. I have already implemented a simple extraction of jump labels, but the generated labels are not too useful.
On the other hand, if you want to debug arbitrary programs, you can not rely solely on symbol tables to aid the disassembler.
My disassembler already uses a map I got somewhere on the net, but it is rather sparse. I tried google with "VIC-20 memory map annotation", but did not get useful results. So if you don't mind, please send me the map.
Post a Comment