Re: DMA INTERFACE for SAM COUPE
Very interesting. I didn't expect it to work well enough to be of use on SAM, given how limited memory accesses are. Does the CPU manage to run at all while the DMA is active? Is it possible to achieve the same result with an external board replacing the internal CPU? My soldering skills aren't up to replacing the existing CPU with a socket! Of course, your news might trigger you-know-who into action again... Si On 08/08/2015 23:46, VELESOFT wrote: Here is my version of DATA-GEAR (Z80 DMA interface for SAM COUPE). It's internal version for connection instead original Z80CPU (need replace CPU with socket). http://velesoft.speccy.cz/other/dma%203Trd+3Twr-long.png VIDEO (sorry, bad quality and low FPS). Almost fullscreen scroll 25 fps on real sam coupe. http://velesoft.speccy.cz/other/DMA_SAM_001.MPG
Re: Bug in game Oh No! More Lemmings
On 11/08/2014 12:19, Solaris104 wrote: I played this game and I found a bug in the level 3 (rating crazy), password NEYLEKNO. Does it exist any fix and level codes for this game? Solaris104 What is the bug you think you found? I've just tried it here and that level does start correctly for me, though I've not tried completing it.. If you have a .SDF disk image for either Lemmings or Oh No More Lemmings, the disk image is incomplete. They are truncated at 80 tracks, but the complete disk uses 82 tracks, and will stop working at one of the later levels that access the missing tracks. I do remember hitting the limit in the original Lemmings game, but I don't know where the problem would be seen with the Oh No More Lemmings. I did try truncating my disk image to 80 tracks to see if I could reproduce it, but level 3 (crazy) still started correctly. If you can describe the symptoms in more detail I'll see if I can reproduce it here. Si
Re: Anyone care to help out?
Hi David, I've still got an audio cable set up from my SIAC, so drop me a line off the list and we'll sort something out. I'm not much of an E-Tracker user, so anything that's as ready to boot and play as possible would be appreciated :) Cheers, Si On 21/04/2014 00:03, David Sanders wrote: Hi All, As mentioned in a previous post, my real Coupe was mercilessly destroyed by t'mother. I'd really like a chance to hear a bunch of my E-Tracker stuff on a real SAA-1099. Does anyone have any kind of setup that'd make recording some of this easy? The emulation seems pretty good, but it still just feels too clean! If anyone's willing to help out, please let me know :-) Thanks in advance, David
Re: SimCoupe crashes?
The fault location doesn't ring any bells, though it appears DirectDraw on Vista (or later) is emulated using GDI+. I'll send you an updated build to try, which also uses D3D by default so it should look much better than the blocky software version. I'll still see if I can reproduce the issue using the same drivers and my similar hardware. Si On 06/01/2014 22:32, Stefan Drissen wrote: While travelling down memory lane, SimCoupe kept crashing on me if I moved the SimCoupe window while it was doing exciting stuff (playing e-tunes ;-)). It occurred a few times repeatedly, the event viewer reports the errors as: Faulting application SimCoupe.exe, version 1.0.0.0, time stamp 0x44c1277a, faulting module gdiplus.dll_unloaded, version 0.0.0.0, time stamp 0x515ba857, exception code 0xc005, fault offset 0x6df774b2, process id 0x2624, application start time 0x01cf0b2e08734b0c. Faulting application SimCoupe.exe, version 1.0.0.0, time stamp 0x44c1277a, faulting module gdiplus.dll_unloaded, version 0.0.0.0, time stamp 0x515ba857, exception code 0xc005, fault offset 0x6df774b2, process id 0x1694, application start time 0x01cf0b2df0d4633c. Faulting application SimCoupe.exe, version 1.0.0.0, time stamp 0x44c1277a, faulting module gdiplus.dll_unloaded, version 0.0.0.0, time stamp 0x515ba857, exception code 0xc005, fault offset 0x6df774b2, process id 0x2534, application start time 0x01cf0b2c520b8aec. Using Vista x64 (aero theme) with nVidia 331.82 drivers on a GTX 660 Regards, Stefan
Re: Sim Coupe
I've got a Win32 binary for the current SVN build that you can try... The sounds code is built-in now, so there won't be a problem with that particular SAASound.dll. Most virus-scanner false-positives I've run into have been related to using UPX to compress the modules. Seems odd that an open format and reversible compression would make any difference to the detection. Si On 25 Jun 2013, at 09:20, Adrian Brown adr...@apbcomputerservices.co.uk wrote: Hmm, damn, I thought it was probably an issue with my version, hence trying to sort it and getting the sound dll killed and then having issues getting a new vversion, but still it refuses to run on my new windows 7 system. Starts up but I just get a green screen L Ill have to grab the code and have a look see I guess :D not sure why, always did run on windows 7. From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Adrian Brown Sent: 25 June 2013 07:28 To: sam-users@nvg.ntnu.no Subject: RE: Sim Coupe Yer – that’s my problem. Ill send it to avast From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Balor Price Sent: 25 June 2013 00:02 To: sam-users@nvg.ntnu.no Subject: Re: Sim Coupe Yeah same here - got an error through Avast - it thinks Dave Hooper's SAASound.dll is a virus. I supressed it but the anti-virus wasn't having any of the sourceforge download. So I did a naughty and got it from here: http://www.rom-world.com/file_emu.php?id=21 Howard On 24/06/2013 23:15, David Sanders wrote: On 24 June 2013 23:05, Adrian Brown adr...@apbcomputerservices.co.uk wrote: This is most odd, I haven’t got a virus, it’s a false positive that killed the dll. However I get internet explorer cannot display the webpage error - the full link it goes to ishttp://sourceforge.net/projects/simcoupe/files/simcoupe/SimCoupe%201.0/SimCoupe-1.0.exe/download?use_mirror=dfnr= That link works fine for me in Chrome / Windows 7. -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Andrew Gillen Sent: 24 June 2013 21:24 To: sam-users@nvg.ntnu.no Subject: Re: Sim Coupe Not a lot of use to you I realise, but I can confirm it is working fine here, too. Cheers Andrew - Original Message - From: Stephan Haller no...@froevel.de To: sam-users@nvg.ntnu.no Sent: Monday, June 24, 2013 9:15 PM Subject: Re: Sim Coupe Hmmm ... wasn't a problem either. The md5sum of the exe file I downloaded is bbf240d96fb6896d4394c813ae634726 tmp/SimCoupe-1.0.exe Maybe your virus killer is killing this exe? Am Montag, den 24.06.2013, 20:52 +0100 schrieb Adrian Brown: Yer but try and get the windows exe ;) -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Stephan Haller Sent: 24 June 2013 20:22 To: sam-users@nvg.ntnu.no Subject: Re: Sim Coupe Hi Andrian, that's strange. Sourceforge is listing all files to me. Try http://sourceforge.net/projects/simcoupe/files/simcoupe/SimCoupe%201.0/ Regards, Stephan Am Montag, den 24.06.2013, 20:11 +0100 schrieb Adrian Brown: Anyone know where to get simcoupe from - sourceforge seems to be empty? My virus killer seems to have eaten the sound dll :( Adrian -- Stephan Haller www.froevel.de Systemadministrator EMail: no...@froevel.de Telefon: 02202 / 45 97 95 Mobil: 0176 / 63 86 30 21 Jabber (bevorzugt): no...@jabber.froevel.de ICQ: 33955897
Re: SAM floppy drive.
I'm sure I've got a spare I can donate... I'll have a check and be in touch! Si On 01/06/2013 17:01, Chris Pile wrote: Hi SAMsters, A bit of a long shot really, but thought I'd try here! Does anyone have a spare (working) SAM floppy drive and controller they'd be prepared to get rid of, preferably cheap! I only have a single floppy at the moment and I need to test something that uses dual floppies. Most of my testing can be achieved on the excellent SimCoupé - but I need to do some timing tests with real hardware. I'm aware Colin sells replacement drives/controllers, but 50 sheets is a little too steep for me at the moment. So, if you've got one you don't want then please let me know. Must be a fair bit cheaper than £50 though. ;) Alternatively, I do have a Quazar's SAM PC keyboard interface, brand new (still in its box and never fitted), which I would do a straight swap for a SAM floppy drive and controller if that appeals to anyone? Cheers, Chris.
Re: SAM / +D Help needed
On 24/03/2013 01:51, Tommo H wrote: I got as far as discovering that SAM Coupé diskimage Manager v1.12 by Edwin Blink would allow you to liberate the files from the Sam disk image to a Windows PC; there must then be a tool for throwing them onto a Spectrum TAP or DSK. Transferring the files should be easy if they're just code files... Load them from disk into RAM in SimCoupe, then export as raw binary files (Shift-F4). Then import the binary files into RAM in a Spectrum emulator (most support it), and save out to TAP or +D disk as normal? If you're using Edwin's diskimage manager to extract files from a .dsk for that first step, be sure it's an legacy uncompressed disk image (819200 bytes). I've exchanged messages with David off the list over the file transfer, so I thought that part was already done. The difficult bit is probably the unknown compatibility between SAM and Spectrum versions of PAWS. If you're lucky they're the same format and it just works. Si
Re: Sam Coupe project..making a real SAM in hardware ??
Will any clones still have a 6MHz mode, with memory timings identical to the original hardware? A higher proportion of SAM software depends on them for video effects, compared to what you'd see on the Spectrum. Si On 24/03/2013 14:28, Leslie Anderson wrote: Hi. I'm new to the SAM COUPE group and wondered would anyone be interested in making a homebrew SAM-COUPE ?? It would have an improved spec. on the original: Z84C0020 20MHz Z80 512K SRAM ( KM68400,K6T4008 etc) 64K or so EEPROM W27C512 CPLDs as glue logic for video, memory and I/O decoding, serial and parallel input,output RS232, LPT1 etc SAA1099 sound chip V9958 +128K RAM as second VDP for sprites etc possible using a micro-controller for PS/2 mouse / keyboard and joystick input. Should cost about £30 for ICs and stuff plus another £50 for a one-of prototype PCB. Anyone interested ?? Best Regards
Re: SimCoupe running in the Raspberry Pi
On 17/02/2013 11:44, Marcos Cruz wrote: It works fine. Only the full-screen mode does not work on X Window. Simon explained there's no solution yet. I tend to run outside of X as it's slightly faster, which can be needed for demos that change much of the display each frame. Though I've just tried in X and it does still work for me: https://dl.dropbox.com/u/2553707/simcoupi_x.jpg The problem I mentioned about not running in X was using OpenGL SE, where there didn't seem to be Broadcom driver support for it (yet?). GL SE support still only exists in a private branch at the moment, waiting on SDL 2.0 to be finalised, and Pi support to be improved generally. I did whether it was worth the effort for a Pi-specific version of the video code, but if I can get it for free through SDL I'll get to spend that time elsewhere! SimCoupe makes the Pi's CPU to work a lot (70%-90%) but the maximum SAM's speed is good enough (200%-250%). (I have overclocked the Pi to 800 MHz). ~250% sound about right for maximum running speed with the current software version. I'm hoping that the switch to GL SE will give a bit more time back to increase that, as well as 50Hz hard-synced video for smooth scrolling. My Pi has 256 MiB; I've ordered a 512 MiB one because 256 is not enough for some working sessions I've got a 512MB model for development, but SimCoupe will always be fine on the 256MB version. I'll probably create a stripped-down version that boots directly into SimCoupe, with less other junk loaded on startup -- similar to Allan's Linux root and boot disks back in 1996 :) Si
Re: WoS: spammer
On 15/01/2013 20:51, Stefan Drissen wrote: Just a heads up that a spammer has hit worldofsam.org with four crap comments. I've deleted them now. The username of 'sam' felt a bit more targeted than usual! Si
Re: Which colors for a grayscale?
Hi Marcos, The SAM palette is make up using 2-bit RGB plus intensity, which bitwise is: xGRBigrb. For pure greys you'd use: = 00 = 0 0111 = 07 = 7 1000 = 08 = 8 = 0f = 15 0111 = 70 = 112 01110111 = 77 = 119 0000 = 78 = 120 0111 = 7f = 127 The SAM demo tape astronaut image uses cyan to fill some of the gaps, which duplicates black and white on the ends: 0, 0, 8, 5, 7, 13, 15, 82, 112, 90, 120, 117, 119, 125, 127, 127 That's maybe as good as you'll get for a 16-colour palette. Si On 19/12/2012 20:43, Marcos Cruz wrote: Hi all, In order to automate and simplify as much as possible the process of importing images into the SAM and avoid the palette conversion problems, I'm tinkering with the Netpbm raster formats (http://en.wikipedia.org/wiki/Netpbm_format). BMP and others could be used too, but Netpbm files have two encoding variants (ASCII and binary) for every type (PBM, PGM and PPM), what makes them very versatile in this case. The Netpbm images are created with Linux tools and the SAM does the final conversion, PLOTing the image pixels with the desired equivalent colors and GRABbing it. The first tries with a grayscale image look promising, but I need to choose 16 grays from the SAM palette (0, 7, 8, 15, 112, 120, 127...?) I'm afraid there are less than 16 gray tones, and blue must be used to complete the set. Am I right? Does anyboy know which are the best 16 SAM original colors for a grayscale? Thank you. Marcos
Re: 'BMP to SAM' by P. Crompton, in Fred 46
Hi Marcos,
If it's of any use, I did a quick hack version of my shamview converter to keep
the full image at 16 colours. It scales the source image to 256x192 and
converts to SAM palette, then picks the top 16 colours to use for a final
conversion. Script is here: http://obo.homeip.net/img2sam.py
It doesn't give a properly optimised palette, and dithers for any missing
colours, but those could probably be improved upon (tolerance for nearest
colour matching perhaps). It also generates PNG output, but converting to SAM
mode 4 and wrapping in a disk image probably wouldn't take much work.
Si
On 12 Dec 2012, at 03:44, Marcos Cruz wrote:
Hi,
I've edited the WoS' page about Fred 46
(http://www.worldofsam.org/node/567) to include an interesting program
I recently discovered while searching all disk magazines for useful
tools and info: 'BMP to SAM' by P.Crompton ('SAM to BMP' is there too,
but I don't need it).
I've been tinkering with it in order to import images and grab them for
a project. It works fine, but it was not easy to create BMPs with the
exact requirements. At the moment I use a combination of manipulations
with mtPaint and commands from the netpbm tools (both in Debian), though
the palette conversion is not working fine yet. Fortunately, the mail
list archive is a good source of info, e.g. the following old threads:
http://news.gmane.org/group/gmane.comp.systems.sam-coupe/thread=1422
http://news.gmane.org/group/gmane.comp.systems.sam-coupe/thread=22779
I hope I'll eventually find out a way to automate the conversion from
the original BMP (or other format) to the final MGT disk image with the
final mode 4 screen.
I suppose P.Crompton is the same Paul Crompton mentioned in other Fred
issues. Can someone confirm? If so, I'll complete the entry.
By the way, can he be contacted? I'd like to take a look at the Z80
source, maybe do some changes or translate the algorithm. It wouldn't be
difficult to dissasemble anyway.
Marcos
--
http://programandala.net
Re: text spooling
On 16/11/2012 18:59, Thomas Harte wrote: What's your policy on native code? I ran a quick test with: I try to avoid native code in the SDL version, where possible, but it seems like it might be the best option. It can probably go in SDLMain.m without too much trouble -- thanks! :) Si
Re: buggy KEYIN; MasterBASIC's tokenized format; buggy RENUM
On 15 Nov 2012, at 22:57, Marcos Cruz wrote: What do you mean auto-typed? Text spooling? Yep, that's it! It's currently a Windows-only feature at the moment, but I'll extend it to support other platforms. AFAIK SimCoupe lacks a file spooling option (in fact it is what I need: SimCoupe to type the content of a text file of the host machine). I'll add file spooling for non-Windows platforms, and clipboard paste once SDL 2.0 is supported. The Windows version will likely remain clipboard only, since sniffing the encoding from text files is just too unreliable. there are many labels in the imported KEYIN-ed code. I'll remove them too --just to see what happens. I'll be interested to hear how you get on with this. If it does fix it, labels are definitely to be avoided until the ROM issue is tracked down and (hopefully) fixed. Si
Re: text spooling
On 16/11/2012 16:15, Marcos Cruz wrote: the text is converted before auto-typing it. Isn't it? I mean non-ASCII characters. Yes, in the simplest case it's just to map £ and © to the special codes needed for SAM use, and to drop CR but convert NL to CR. Though I also use the Win32 API to do a more thorough transliteration to the closest ASCII equivalent (mostly stripping diacritics). I also added manual transliteration of Cyrillic characters to attempt to preserve comments in a batch of Russian BASIC listings. For the other ports I was planning to use iconv to do the main transliteration step. Under Linux iconv (part of libc-bin) appears to include the support I'm after. Mac OS X is still using the traditional libiconv, which gives strange results with the accents separated out (coupé - coup'e). If I can't find a quick and easy solution for that I'll just drop transliteration support. I'd rather spend my SimCoupe development time on emulation, not text conversion! But I think automatic translation during spooling has some drawbacks: first, it would be useful only for non-ASCII characters (mainly, foreign language letters) provided by the SAM (mainly, by MasterBASIC) --or for all characters, in case the file is encoded in any ASCII-incompatible format, e.g. UTF-16, what is not common; That uncertainty is the reason for only using the clipboard in Windows -- I get the content in Unicode, so I don't need to guess the character encoding. It appears SDL 2.0 (still under development) will be able to provide the clipboard contents in UTF-8, which should give similar results when combined with a working iconv. character translation done by the programmer in the source. There will always be special cases, particularly for that kind of private encoding scheme. I think it'd be best to require the user to convert the text before spooling, with automatic translation disabled in SimCoupe. Therefore, in my opinion, a simple and versatile option could be: first, assuming the spool file is encoded in an 8-bit ASCII-compatible charset (the actual encoding is irrelevant); Assuming spooled text files are UTF-8 on non-Windows platforms might give a similar success rate to assuming iso-8859-1 under Windows. I did implement file spooling in the Windows version, but I felt the character coding uncertainty would generate poor results and too many support e-mails, so I took it out. It's tempting to do the same for non-Windows platforms, but I might give it a chance. and second, feeding it as is to the SAM, without translation (of course beside end of line and maybe other control characters). I'll probably add options for no translation, minimal translation, and full transliteration. Hopefully even without that help the spooling process will still make your life a bit easier :) Si
Re: New Game: Dave Infuriators
It's great to see more new content! I just wish I could get more than 2 steps up on the first screen. I'm just recovering from a Super Hexagon addiction, so I do like my games tough ;) Si On 14/11/2012 16:08, Andrew Gillen wrote: Hi, just to let you know I have finally finished writing Dave Infuriators. Simple platform game against the clock. Instructions can be found in the readme.txt in the archive. Played with just two keys : change direction and jump, so following the trend these days of minimal controls. Took longer to write than it should with life's distractions and other projects. Also didn't end up quite how I envisioned but here it is nevertheless! Http://www.blackjet.co.uk/download.php?d=dave-infuriators Requires 512K SAM. Cheers Andrew
Re: buggy KEYIN; MasterBASIC's tokenized format; buggy RENUM
This sounds like a problem I was looking at with Josef a few months back, where long ported programs failed on SAM. As far as I could tell it was a bug with LABEL management -- his problem listing used many labels (no use of KEYIN). I was able to narrow it down to a boundary case, as demonstrated with this test program: 1 PRINT Running... 2 FOR x=1 TO 111 3 PRINT at 1,0;x 4 KEYIN STR$ (x*2+100)+ LABEL l+STR$ x+: PRINT +STR$ x+: STOP 5 KEYIN STR$ (x*2+101)+ REM x 6 NEXT x 7 CLS : STOP 8 REM -X 1) Type that into a freshly booted SAM, run it, then wait for the counter to reach 111. If you then type CLEAR it gets stuck and never returns. 2) Next, do the same again but remove the 'X' from the end of line 8. This time the CLEAR command will finish after about 30 seconds, which I believe is the time taken to rebuild the LABEL table from scratch. To rule out a problem with KEYIN, I used LLIST to write the program to a text file using the SimCoupe printer option. I then auto-typed the contents back in to a freshly reset SimCoupe, so KEYIN was never actually executed, even though it was still part of the listing. I was still able to demonstrate the same issue, with the single character difference. My guess is that the final label might be at some kind of page boundary, which trips up the code building the table. I haven't tried to look into it -- any volunteers...? I noticed your program also uses labels, though not as many. It might be worth trying to remove the labels, to see if that magically fixes it? Si On 15/11/2012 18:17, Marcos Cruz wrote: Hi all, Some time ago I wrote a toolkit to write MasterBASIC programs with the Vim editor (http://vim.org) and import them into SimCoupe (see http://programandala.net/en.program.mbim). It didn't work because the KEYIN command has bugs (in SAM BASIC, but MasterBASIC didn't fix them). In fact, a similar tool for ZX Spectrum's Beta BASIC (see, in Spanish: http://programandala.net/es.programa.bbim) works like a charm: I can write Beta BASIC code (in an improved format with new features) with Vim, and then, with a keypress, convert it to real Beta BASIC and create a fake disk image ready to be imported into the Beta BASIC interpreter. It would be nice to work the same way with the more powerful MasterBASIC... Is there any patch to fix SAM Coupé's KEYIN? I'm afraid not. I thought an alternative: I could write a program to convert the source code into tokenized MasterBASIC and copy it into a SAM disk image. But the tokenized format is not fully described in the Technical Manual or the MasterBASIC User Manual (though many details can be found there and others are similar to the ZX Spectrum format). In theory this approach is feasible, but much more complex. Any other idea? I'd like to develop some project in MasterBASIC, but its own editor would be a pain compared with the features of a modern editor. Beside, also the RENUM command is buggy, what is a serious limitation. Marcos
Re: New Game: Dave Infuriators
The last 20 seconds on level 6 might kill me, so I've been having a bit of a break from it. It's s addictive though. Si On 15/11/2012 20:40, James R Curry wrote: Don't get me started on Super Hexagon. Terry Cavanagh insisted to me at Fantastic Arcade that My game's not difficult after I repeatedly died at the 7 second mark. I'm a bit better at it now. I do love the game. On Thu, Nov 15, 2012 at 2:36 PM, Simon Owen simon.o...@simcoupe.org mailto:simon.o...@simcoupe.org wrote: It's great to see more new content! I just wish I could get more than 2 steps up on the first screen. I'm just recovering from a Super Hexagon addiction, so I do like my games tough ;) Si On 14/11/2012 16:08, Andrew Gillen wrote: Hi, just to let you know I have finally finished writing Dave Infuriators. Simple platform game against the clock. Instructions can be found in the readme.txt in the archive. Played with just two keys : change direction and jump, so following the trend these days of minimal controls. Took longer to write than it should with life's distractions and other projects. Also didn't end up quite how I envisioned but here it is nevertheless! Http://www.blackjet.co.uk/download.php?d=dave-infuriators Requires 512K SAM. Cheers Andrew -- James R Curry 8...@itdoesntsuck.com mailto:8...@itdoesntsuck.com
Re: Nyan Cat
On 12/05/2012 22:34, Aleš Keprt wrote: We have the program done, including graphics and music. I also added a tiny text scroller and now I need to write some text to put there. :-) Did you ever finish this? It'd be great to see how it compares to the Speccy version. Si
Re: S. Goodwin and MasterBASIC Sources
On 04/09/2012 16:23, sam.co...@centrum.cz wrote: According to his other words (and the SAM Revival interview with Mr. Wright) I think these discs have original asm-texts... Anyone could help to contact Simon? I asked Simon about this at the Spectrum 30 show yesterday. He does have some partially recovered source, but not something that will assemble successfully. He's been too busy to look into it further himself, but I've asked if I can borrow the disks for re-dumping, and see what we can do to recover more. Si
Re: MESSENGER interface
On 02/08/2012 23:16, VELESOFT wrote: Exist schematic or PCB photos of this interface ? I don't have a schematic, but I have some photos somewhere. I'll send them on if I can find them, or take some more. Si
Re: One for Simon Owen re : Simcoupi
On 30/07/2012 17:39, wayne wrote: Tried to build Simcoupi on my recently aquired RPI. There was a missing component in the SourceForge path, fixed now! The newer distro also simplifies things slightly, so I'll post updated instructions when I get a chance. In the meantime, try this updated binary built on Rasbian: http://simcoupe.org/files/simcoupi-r1439.zip You might get the odd sound underrun reported in the console when entering and leaving the GUI, especially if you're running it from within X. I've never seen the error you reported, though I misread your message and didn't try the old binary. OpenGL SE support is still a work in progress, but should hopefully give a bit more speed, and options for 50Hz sync (with audio resample). Si
Re: Cross-development tools
On 14 Jun 2012, at 09:23, Chris Cowley wrote: I have my favourite text editor and pasmo set up, which I use for occasional speccy stuff, and have augmented this with pyz80 I use the same mix of pyz80 and Pasmo for SAM and Speccy development, along with my favourite text editor. In both cases the editor launches the assembler, and if successful it opens the disk image in SimCoupe. Using autoexec (pyz80) and end (Pasmo) directives to auto-run the code makes for a very fast development cycle. JAM Assembler can do all of that for the SAM side in its own IDE, though I'm a sucker for my usual text editor, so I have to admit I've not used it very much. The assembler does support some extra features over pyz80 though, which may be useful. I also use Makefiles (or a make.bat on Windows) for managing any additional input dependencies, such as image conversion and table generation. Again, it's just so a single command does everything automatically. The only time I need to get my hands dirty is for proper releases, where I'll usually add a BASIC loader and keep data as separate files on the disk. Have also got SAMdisk and DiskManager for manipulating disk images, which seem to be working nicely, but... I generally only need SAMdisk when transferring disks to real hardware for testing. I still assemble on the PC, even when I can only run on real hardware (Trinity ethernet mostly). Copying the output DSK to a BDOS record on a Compact Flash card and moving that to the Atom Lite on my SAM takes seconds. For larger code listings, or if the launched program crashes and takes out the development system, it's usually faster. Even transferring DSK via floppy isn't too slow if you use the --minimal flag to only copy the used portions of the disk. It's been a while since I've used DiskManager, especially since pyz80 can add a samdos2 file to the start of the disk using the -I command-line option. SimCoupe will boot disks without it, but you still need it for cold booting on real hardware, so it's recommended to add one. I used to use DiskManager for importing images to SCREEN$ format, until... What I really could do with is a utility (preferably with a palette editor) for drawing graphics (tiles, sprites) that runs on Windows and spits out either DEFBs or binary files that I can INCBIN. Does such a thing exist? I mainly use Paint Shop Pro 7 for most SAM image editing, with a .pal file loaded containing the 128 SAM colours. I just draw sprites on a big image, keeping to a grid spacing, and making sure I stay within the 16-colour limit (there's a colour counting option). My development is usually split between Windows and Mac, and this is one area I've struggled to make equivalent. The image editors I'm using (Pixelmator and Acorn) don't support working directly with palettised images, and just convert them to RGB for editing. So I'm generally limited to making only small changes, and hoping I stay within the colour limit. Failing that, something that has a reasonable stab at converting PNGs or GIFs into a form I can use in asm would be useful. I've got a Perl script to extract graphics files from a palettised PNG image and save in raw SAM (or Spectrum) format, which can be included in the .asm using INCBIN. I think the Spectrum version of my png2bin.pl is in the pacemuzx project on GitHub, but the SAM version is likely missing as I was (and still am!) rewriting it. I wanted something script based with minimal dependencies, so I could use them on whatever OS I happened to be on. Si
Re: Cross-development tools
On 14 Jun 2012, at 22:50, Andrew Collier wrote: I recently discovered Pixen, which is designed for just that sort of thing. Mac OS only, though. That looks promising — thanks! It's no problem being Mac only as it fills the hole I had with palette-based pixel editing. Though curiously my sample palette.png file that I thought had all 128 SAM colours is only showing 126 in the list in Pixen. I'll have to check it back in PSP to see if it's my mistake. To get those images onto the Sam, I (like everybody else, apparently) wrote a script which reads image files and outputs in various formats. Mine's in Python. I almost wrote my updated version in Python, but there didn't seem to be any built-in support for reading PNG images (unless I missed something?). I used PIL for shamview, but that wasn't part of the standard Python installation on either Snow Leopard (at the time) or Windows, but it was under Ubuntu. I found an unofficial build for Windows, and managed to copy a MacPorts-built extension to the standard Mac version, but it wasn't a dependency I really wanted for my build tools. After all that I fell back on processing the PNG file directly, and I'd already got Perl code to do enough for what I needed. Ah well. Si
Re: BorderTron 3000 - SAM Coupe Edition
On 5 Jun 2012, at 01:32, Chris Cowley wrote: I've done a SAM-specific version of my little BorderTron Nice work — didn't expect you to do it so soon! My first design ended up off the left of the screen, so perhaps it's worth reducing the editable area to just the visible display? That'll typically be 2+32+2=36 blocks. I've a Mac-specific bug report, and some extra questions, though I'll save those for IRC :) Si
Re: Quick attempt at a scroller
On 18 May 2012, at 00:56, Tommo H wrote: If I have, say, 40% of a frame to spend on it, how many sprites, and how large, is it realistic to expect to be able to draw and un-draw? Maybe around 4-5 sprites of 16x16 pixels? IIRC my Pac-Man emulator has about half a frame to draw 6 sprites of 12x12, plus a couple of background tiles, including save/mask/draw/restore. For an extra boost perhaps generate the sprite drawing code with knowledge of the data (like Chris did in SAM Defender) — bonus points if you prepare that at runtime. It's nice to have some fresh on-topic content to read, so keep posting! Si
Re: border effects and tricks
On 13/05/2012 10:14, Andrew Gillen wrote: There seems to be a lot of talk about timing critical border effects for the ZX Spectrum. Anyone got any information on achieving the same sort of effects on the SAM? It's much the same on SAM, just with different timings and alignment: - longer delay needed from frame interrupt to start of effect - 2 visible blocks per OUT (C),r rather than 3 for the Spectrum - 384T per line rather than 224T/228T to 48/128K - 24 OUTs needed per line rather than 19 for Spectrum - narrower (and possibly taller?) border compared to Spectrum - contended memory+ASIC, rather than just ULA for Spectrum border At least there's only a single SAM model to worry about, and no early/late differences. imported the result into Sim Coupé, the result encouraged, but equally frustrated, it created some nice patterns, but not quite the patterns I wanted. It shouldn't take much to tweak for SAM timings. Chris would probably be up for supporting them as an extra option too, especially if the work has been done to know what's needed :) Doing it all yourself from scratch will probably give you a better idea of how it works. I rarely work out all the timings by hand anymore, and just rely on trial and error. Step through it in the SimCoupe debugger and you'll see current line positions, and it being built up... Si
Re: border effects and tricks
On 13/05/2012 10:14, Andrew Gillen wrote: it created some nice patterns, but not quite the patterns I wanted. Try working from this: http://obo.homeip.net/BorderSAM.zip The visible width is 36 blocks, and each out covers 2 blocks. That means 18 OUTs for the effect plus 6 more for invisible padding between lines. Adding a NOP after an OUT adds a single block for odd widths. There must be an even number of NOPs in each line for timing, with any spare NOP added after the padding OUTs. For every 2 NOPs added you must remove an OUT. Technically, 2 OUTs (8T total) should be needed per extra block, but the ASIC contention alignment during the border write rounds it up anyway. I've kept the number of vertical lines the same as the original code, though you can see more than that on a real SAM. There's also some interrupt re-entrancy with the current code, but it's allowed for in the timing delays. I've just had a chat with Chris on IRC and there may be SAM support in the editor program at some point :) Si
Re: Sam Coupe games - multipack available as DSK/SAD image?
On 06/05/2012 11:48, Mike Nicholas wrote: The disks I purchased no longer work and I wondered if anyone knew if it is possible to get a DSK/SAD image for these games? I have Multipack 1 in EDSK format (it has a blank track that can't be represented in the simpler DSK or SAD formats). It looks like it's still waiting for distribution permission on worldofsam.org, but since you own it I'm sure we can work something out. I'll contact you off the list... The main games I am currently looking for are the multipack games. Was there more that one Multipack bundle? If so, do you have a list of what was on the others? Si
Re: Party like it's 1992, or 1984, or whatever.
On 05/05/2012 01:27, James R Curry wrote: Hangs on boot in SimCoupe for me BDOS appears to get stuck in a loop accessing the 2nd drive. With an Atom interface connected it's waiting for the HDD to be ready. With a floppy drive present it's waiting for the FDC data register to change, which never happens. I'll need to dig a 2-drive SAM out of the loft to check it. It's either a BDOS assumption about an Atom being connected or a SimCoupe FDC bug. For now, change the second drive type to None in the options (Tools-Options-Drives-D2) and it'll boot up OK. Si
Re: Party like it's 1992, or 1984, or whatever.
On 05/05/2012 14:52, David Sanders wrote: the only issue I'm having is that E-Tracker 1.2 is utterly confused by it - to the point that I actually have to disable the 2nd drive to get it load modules. The good news (well, for me!) is that it's the same with real hardware. Unplugging the second drive fixes the boot hang, so it's a BDOS issue. I don't suppose anyone has a workaround for this? The AtomLite version of BDOS doesn't suffer from it, so it may be enough to use that instead. It also depends if you're using any newer features of BDOS 1.7, as I think the AtomLite version is based on 1.5a. I'm not familiar with how E-Tracker accesses disks, but I guess it could be patched so it doesn't touch drive 2. Si
Re: Party like it's 1992, or 1984, or whatever.
On 05/05/2012 14:52, David Sanders wrote: the only issue I'm having is that E-Tracker 1.2 is utterly confused by it I get a Fatal Error message accessing the disk with Atom BDOS, AtomLite BDOS and even SAMDOS v2. I noticed the E-Tracker comes with MasterDOS, so perhaps it's relying on features in that that's causing the problem? Si
Re: Party like it's 1992, or 1984, or whatever.
On 05/05/2012 17:15, Simon Owen wrote: perhaps it's relying on features in that that's causing the problem? I can confirm there's a sprinkling of MasterDOS-specific code, including DSTAT and DIR$, which will need to be re-written. On the plus side, all the disk access appears to be done from BASIC so it should be fixable. It'd be nice to have a version that worked from CF too. Any takers? ;) Si
Re: Nyan Cat
On 24 Apr 2012, at 21:29, Simon Owen wrote: Getting most of it running probably wouldn't take very long, but getting the timing right could be a challenge. Changing the 128K screen flips and crudely tweaking the DJNZ timing loops gives this: http://obo.homeip.net/nyanhack.gif (loop every ~4 seconds, not seamless) The rainbow timing slips out below the cat, so the scroller display is completely wrong. Fixing it would be fiddly even with source code, so I'm not convinced it's worth additional effort to patch the Speccy version. Roll on the native version(s)! Si
Re: SimCoupi
On 25 Apr 2012, at 15:23, Andrew Collier wrote: I don't have a copy of KR to hand, but I reckon this is ambiguous (i.e. the value of g_dwCycleCounter7 depends on the whether this is evaluated before or after the += 4. Honestly I'm a bit surprised that the left hand side is an lvalue at all…). I don't remember how it came to be like that, but I'd suspect it was fastest with VS6 back in the day. It was pretty nasty, so good riddance to it. Thanks for the fix! :) Si
Re: Nyan Cat
On 23 Apr 2012, at 21:35, James R Curry wrote: Just port the original. I've had a quick look and there are oodles of unrolled code blocks and fixed delay loops for display timing. Getting most of it running probably wouldn't take very long, but getting the timing right could be a challenge. It might be worth a try, if I find the time, and if someone else hasn't already done it by then. It'd still be nice to have a native SAM version to add to the official list, but it sounds like others on the list have that covered :) Si
Re: Nyan Cat
On 23/04/2012 16:16, Tommo H wrote: Vaguely related: does anyone know where I can get hold of Sam dos as a binary blob, outside of a disk image, for the purposes of being able to assemble things conveniently? Most of my SAM projects on GitHub should include samdos2. They also use pyz80's -I option to add it to the output image before the auto-executing code file. That's usually plenty for development, even if I manually add a BASIC wrapper later for the release. Si
Re: Nyan Cat
On 23 Apr 2012, at 18:10, Tommo H tomh.retros...@gmail.com wrote: The SDL you've linked with appears to be broken under 10.7 in some ways, especially relating to the way the new OS supplies help in restoring sessions It might be worth checking you're using SimCoupe 1.0a for OS X, as that was a minor update to fix a Lion issue (crash on startup). That should work back to 10.4, as well as on PPC. Future releases are likely to require 10.5 or later due to the switch to Xcode 4. Si
Re: Musics
On 20 Apr 2012, at 17:25, Aleš Keprt wrote: I’d like to know why do you use Amstrad CPC file format, instead of a standard Sam Coupe one (DSK/MGT or SAD). EDSK has been an adopted format in the SAM scene at least as far back as 2005. It's the only way to preserve some disks in their original format, allowing for unformatted tracks, disk errors and other custom-formatting tricks. EDSK seemed like a reasonable solution at the time, without inventing yet another disk image file format. Before that was finalised I did still create SDF as a temporary solution. Only two public disk images ever existed (Lemmings and Prince of Persia), and I don't think the creation tool was every released. All support for SDF was dropped from SimCoupe a few months back, so it's effectively dead. I think we should stick to standard file formats whenever possible to let all those old file utilities work. For legacy use you could convert to MGT: SAMdisk sanxion.dsk sanxion.mgt Si
Re: Musics
Aley, I'd started to type a longer reply to this, but I just can't be bothered anymore. It's clear we have very different approaches to pretty much everything. I'm just not willing to make the same compromises as you when it comes to preserving media. If it doesn't work without modifying it, you need a better quality copy. Si On 20 Apr 2012, at 20:07, Aleš Keprt wrote: You know my disk extractor and other utilitie are dated 199x. And I don’t like this. I think 95% or even more of disks overall don’t need any special disk formats, and there are many software utilities which support simple DSK/MGT/SAD because those programs are much older than 2005. It isn’t a clever idea to design a whole new file format 15 years after Sam Coupe was born and use it for all disks even when it is not needed for most of them. Also those two SDF files can be downloaded from some websites, but I haven’t seen any protected EDSK files anywhere, so I would prefer sticking with the same formats. “Don’t change what works.” Also this is the first time I have seen EDSK file on my own eyes, and I wonder why it has DSK extension when it is not a real old good DSK file. I looked at the file in heax view and I can see Amstrad CPC header in it. Note that I created my SAD format only because it was years before DSK format was known to me, and also I have several 840KB disks which are a bit problematic in DSK especially in some software which automatically expect 800KB DSK only. But otherwise DSK is enough for most of disks. I think it would be OK if we had this file format around 1995 when there was a real big need to backup our disks, but not in 2005 when 99% of disks are converted and possibly cracked to be converted without any special file formats. Aley From: Simon Owen Sent: Friday, April 20, 2012 7:36 PM To: sam-users@nvg.ntnu.no Subject: Re: Musics On 20 Apr 2012, at 17:25, Aleš Keprt wrote: I’d like to know why do you use Amstrad CPC file format, instead of a standard Sam Coupe one (DSK/MGT or SAD). EDSK has been an adopted format in the SAM scene at least as far back as 2005. It's the only way to preserve some disks in their original format, allowing for unformatted tracks, disk errors and other custom-formatting tricks. EDSK seemed like a reasonable solution at the time, without inventing yet another disk image file format. Before that was finalised I did still create SDF as a temporary solution. Only two public disk images ever existed (Lemmings and Prince of Persia), and I don't think the creation tool was every released. All support for SDF was dropped from SimCoupe a few months back, so it's effectively dead. I think we should stick to standard file formats whenever possible to let all those old file utilities work. For legacy use you could convert to MGT: SAMdisk sanxion.dsk sanxion.mgt Si - Mgr. Aleš Keprt, Ph.D. private: a...@keprt.cz, www.keprt.cz office: Moravian College / Moravská vysoká škola Olomouc, ales.ke...@mvso.cz
Re: SimCoupi
On 16/04/2012 16:17, Tommo H wrote: Versus running it on a normal computer, do we get genuine 50Hz output? Setting an option in /boot/config.txt overrides the auto HDMI mode, so it's be easy to force 50Hz (it'd be even better if it could selected on demand at runtime). Composite defaults to NTSC but can be configured as PAL too. I'll probably still need to implement some sound scaling to keep it in sync with the vsynced video. I'll also need to adapt the existing OpenGL code to use OpenGL ES for hardware acceleration. Regular OpenGL seems to be stuck in software mode (glxgears gets just 16fps!). The bundled GL ES demo ran perfectly smoothly, of course. On the sound side, the current ALSA driver is still very buggy. Using it gives a kernel 'oops' when anything tries to use it, so we might have to wait a bit longer for that. Si
SimCoupi
Seems like a promising start: http://simonowen.com/raspberrypi Speed is fine with the normal SDL build, even with demanding titles like MNEMOdemo1 part 2. It ran at about 450% with the emulator turbo button held (max speed but video capped at 5fps). The OpenGL version ran very slowly in X, as though it was missing hardware acceleration. That will be needed for the 5:4 aspect ratio feature, to make it look more like the original display. There wasn't any sound from the 3.5mm jack, and I did see some warnings about not being able to find a sound device. My monitor doesn't have speakers so I haven't checked whether there's anything over HDMI, but I doubt it. I'm using the latest Debian build from 13th April, so I'll need to look into drivers etc. I had to head off to work so it's just a brief look for now... Si
Re: SimCoupi
No special treatment, just some luck in getting an order through on the Farnell website (just before 8am). Perhaps enough people switched to trying phone orders when they opened that the website recovered very briefly? It was pretty much inaccessible before and after that, as anyone that tried will remember! Si On 16 Apr 2012, at 11:51, war...@wdlee.co.uk wrote: That's very cool! :-D God knows how long it'll take before they start shipping RPs to general customers though, after all the promo stuff with schools and such... how'd you get hold of one this early? :-D Quoting Simon Owen simon.o...@simcoupe.org: Seems like a promising start: http://simonowen.com/raspberrypi Speed is fine with the normal SDL build, even with demanding titles like MNEMOdemo1 part 2. It ran at about 450% with the emulator turbo button held (max speed but video capped at 5fps). The OpenGL version ran very slowly in X, as though it was missing hardware acceleration. That will be needed for the 5:4 aspect ratio feature, to make it look more like the original display. There wasn't any sound from the 3.5mm jack, and I did see some warnings about not being able to find a sound device. My monitor doesn't have speakers so I haven't checked whether there's anything over HDMI, but I doubt it. I'm using the latest Debian build from 13th April, so I'll need to look into drivers etc. I had to head off to work so it's just a brief look for now... Si
Re: SimCoupi
On 16 Apr 2012, at 15:48, Wayne Weedon wrote: I just get a 403 error following that link.. Do you have some .htaccess rule in there somewhere? Oops! In case of caching, try this instead: http://simonowen.com/simcoupi I renamed the album title and that must have changed the link somehow. A missing slash in the .htaccess also broke the shamview link a few days ago, so I've not been doing too well overall. Si
Re: SimCoupi
On 16 Apr 2012, at 16:13, Andrew Collier wrote: It still amuses me that the biggest side-effect of my contributions to the Sam scene was to necessitate accuracy in the emulators :) Getting the textured scroller right in part 2 of MNEMOdemo1 was definitely a grail moment, where everything had to be right. Even now, if you build SimCoupe on the Mac and use Clang rather than gcc the scroller is wrong! I've not put any effort into tracking that down yet, but it's almost certainly a compiler issue (gcc and MSVC are fine). Even before MNEMOdemo, the mode-switching scroller in E-Tunes Player was a challenge! Si
Re: SimCoupi
On 16 Apr 2012, at 16:17, Tommo H wrote: Having managed to get hold of a Raspberry Pi differentiates you from 99% of the world; using Google+ differentiates you from 99.9%. The images were uploaded from Picasa, to something which used to be called PicasaWeb. It looks like Google have pulled that into the Google+ brand, with a nag for non-G+ users. I do have an account but don't actually use it. So just the 99% then ;) Looking good though! Versus running it on a normal computer, do we get genuine 50Hz output? That's something I'm aiming for too, as it'd make a huge difference to the experience. Si
Re: ZX Spectrum 'relaunch'
Bonus points if you then run SimCoupe on it, to see if it still feels wrong! I created a quick SimCoupe binary for the Raspberry Pi back in Feb, which I've tested in the development VM under QEMU. Still waiting for real hardware to see how well it runs though. I was kinda hoping I pre-registered early enough with RS, but I've not received one of the magic vouchers yet. I'll have to see if my Farnell order works out... Si On 13 Apr 2012, at 12:43, war...@wdlee.co.uk wrote: There's something very cool about seeing a spectrum do all that (Even if it's really just the case with something else running emulation). I hadn't thought too much about the keyboard, but I suppose that would really be the major difficulty: Getting something that plays exactly like the original but maps to PC keyboard types for the emulator. In theory, you could get a cheap 2nd hand spectrum (even non-working one), a rasberry pi or beagle, and it would come to, what, somewhere under £50? And assuming some relatively easy method of fixing up the keyboard, you could fairly easily create your own. :-) (say's the person who knows nothing about it lol!) It'd be cool if someone created a general guide for doing it cheaply that way, with the appropriate software for the Pi or Beagle, and some extra gadget for the keyboard hookup. Then it would make a nice pack to sell to enthusiasts with little-to-no knowledge of hardware and electronics. Graeme, it would be very cool to see where you get with that! Definitely something you should get working. ;-) Warren Quoting Andrew Gillen a...@joua.net: Hi Warren This idea reminds me of the ZX Spectrum that was modded to run linux. Check out http://www.retrothing.com/2009/04/modding-a-sinclair-zx-spectrum-to-run-linux.html http://www.retrothing.com/2009/04/modding-a-sinclair-zx-spectrum-to-run-linux.html and http://www.youtube.com/watch?v=a0qh7dvaH98 That Beagleboard solution isn't a cheap one, and it requires a fair bit of hackery to get the keyboard sorted, but it looks like a fantastic result. I'd like to try the PI out in a similar capacity, but I lack the degree of expertise in electrical hackery unfortunately to see it through with any confidence of success. If I can find a similar membranous keyboard to that which was used on that set up for a low enough price, it won't stop me trying, though. Much of the experience in playing old games is in using the old kit itself. No amount of PC emulation and full stroke keyboard use can replicate that ZX feel. SAMwise it is different, the keyboard is of a good enough standard for emulation to represent a pretty accurate experience for me. Cheers Andrew -- From: war...@wdlee.co.uk Sent: Friday, April 13, 2012 11:18 AM To: sam-users@nvg.ntnu.no Subject: ZX Spectrum 'relaunch' Off on a bit of a non-SAM tangent (but probably somewhat related for most of us) I came across this the other day: http://www.telegraph.co.uk/technology/video-games/8304237/ZX-Spectrum-relaunch-gaming-goes-back-to-the-future.html Lots of you have probably already heard this, but I don't remember it being mentioned, so thought I would! ;-) Supposedly a company were going to relaunch the zx spectrum this year (by the looks of it, as a 48k speccy keyboard that links up to an iPhone or similar to run an emulator), to coincide with the 30th anniversary, but it doesn't look like it's going to materialise any time soon. I know something similar is/was being planned for the C64? However, it got me thinking... Obviously in this day and age, many of use want to enjoy the retro gaming experience, but we haven't exactly got the space to keep things set up. I intend to have my SAM set up permanently at some point, but I very much doubt I'd ever get the space to dedicate to other systems, so clearly something that pleasantly replicates the original experience quickly and easily with modern advantages would be a pleasing alternative. So I figured, what would make an easy to use 'spectrum' emulator for playing all the old games? You'd want HDMI output for ease with modern televisions, SD card storage, and have it all fit into one of our old rubber keyed friends. How do you do this on a budget at that size? The first thing that popped into my head, is the Raspberry Pi (if it ever gets to selling!!). Small enough to probably fit in a speccy case, with HDMI out and card reader. Surely this could make for a fairly cheap and effective 48k Spectrum emulation experience? I think the Speccy is particularly suited, because let's face it, for most of us it was about the games more than anything. I don't think anything similar would work for the SAM, because what makes that such a unique experience (for me, anyway) is the original and additional hardware in addition to the software. But
Re: SAM HAM viewer
Thanks for that Ian — it does sound very similar to what I was aiming for. Though the standard screen$ capabilities seem very limited, with maybe just 1 change per line? (plus flash) I've had a few more ideas about how to handle a running palette, with it tied into knowledge of SAM's display timings. It might be a while before there's anything to show for it though. Si On 3 Apr 2012, at 18:21, Ian Collier wrote: The Sam does of course have line-based palette changes built into its native SCREEN$ loader (before you say: yes I know that's not quite as sophisticated as what's being discussed). In... oh, 1996, I attempted to write a program that could translate a 256x192 image into a plain Sam screen with palette line changes, though it wasn't hugely successful. It describes itself as follows: Usage: /tmp/ppmtosam [flags] [input] [output] This program converts the named input file (or standard input if none is named) from raw PPM format to a Sam mode 4 screen picture and writes the result in the named output file (or standard output). The resulting file will contain the bitmap (24576 bytes) a palette (40 bytes) and, if required, a line table (4*n bytes) and end with an end marker (character 255). This is the same format as if the picture had been saved to disk on a Sam. If line changes are not requested then the program selects the 16 best colours for the palette. Otherwise the program attempts to calculate a best palette for each line, based on the colours in the surrounding area (the program does not take account of the fact that if several palette changes are made on one line then the later ones will not be available immediately). Alternatively, a picture can be produced using the 14-colour greyscale palette. The picture is not dithered by default, but Floyd-Steinberg dithering may be selected. Valid flags: (default values in brackets) -c Allow line changes -d Produce some debugging information -f Use Floyd-Steinberg dithering -g Produce a greyscale picture instead of a colour one -q Quiet (don't print the number of palette changes) -s Attempt to smooth boundaries caused by palette changes while dithering -A n Look ahead n lines when calculating popular colours for line changes [4] -B n Look behind n lines when calculating colours for line changes [0] -D n Discourage line changes (higher n makes fewer line changes) [4] -k n Keep the first n colours constant when calculating line changes [8] (pen 0 if kept should be a popular dark colour and pen 1 should be light) -L n Use a maximum of L colour changes on a line [2] -M n Use a maximum of n colour changes for the whole picture [127] imc
Re: ZX Spectrum 'relaunch'
Perhaps Aley only sees the practical applications, and what he feels is useful? If something that already exists, why would anyone want to re-invent it, etc. I'm quite the opposite, and a big fan of because-it's-there. I'll happily spend hours investigating and implementing minor emulation features, just because I know there's a difference, even if nothing needs them. While I'm happy to stop short of bus signals for my emulation habit, I do see the appeal in going down to that level to learn more about how things work. An incredibly accurate emulation is just a handy byproduct of the learning process :) The hardware solutions are cool in their own right, but for maximum tinkerability I'll always prefer the software solutions. Si On 13/04/2012 21:36, Thomas Harte wrote: For the purposes of debate, I think the counterargument would be that a software approach is inherently more portable and so more maintainable and more suited to a wide audience. Furthermore, there's no automatic advantage to doing things in hardware, given that these systems are fully deterministic and well understood, other than that it can be easier to get right, but that's primarily because the emulation mindset doesn't normally consider absolute accuracy to be a paramount concern. That's why you very often see people write emulators where interrupt timing is rounded to the nearest whole instruction, palette changes are accurate only to the nearest whole scan line, etc. Authors often prefer to make a subjective judgment about what's 'accurate enough' so that they can prioritise ease of development and/or performance. Summary then: emulation carries no inherent accuracy penalty. Alternatively, as a person who prefers functionality, surely you can see the benefit in emulation, which is all functionality and no form? The hardware becomes a completely orthogonal issue. On 13 April 2012 11:32, Aleš Keprt a...@keprt.cz wrote: I don't share your thoughts. There already exist a lot of Spectrum clones based on real ULAs and real Z80 and imo these are much better alternatives than what you described. You can already buy anything you can imagine. So many alternatives already exist and were created by huge fan base in the past, that I can hardly imagine that somebody can really come today driven by just marketing or business visions and create something significantly better or more compatible or more useful. For example: I personally prefer functionality, not the look of that crappy original keyboard. So I would prefer a PC keyboard, CF memory card instead of tapes or disks, and real ULA (i.e. 100% accurate ULA clone), standard 128 KB RAM, and real Z80 CPU. For other people who prefer or require the original ZX Spectrum case, they can buy a new internals - this was already possible to buy 10 or more years ago. (I personally has a working original ZX Spectrum+ and working original Sam Coupe. :-)) I think you are too focused on emulators - why would anybody put a today's computer with an emulator inside an old ZXS box? It's just funny, not worthy. I prefer either emulator on a proper PC computer, or original 8bit Zilog Z80 in an original box. :-)) Aley -Původní zpráva- From: war...@wdlee.co.uk Sent: Friday, April 13, 2012 12:18 PM To: sam-users@nvg.ntnu.no Subject: ZX Spectrum 'relaunch' Off on a bit of a non-SAM tangent (but probably somewhat related for most of us) I came across this the other day: http://www.telegraph.co.uk/technology/video-games/8304237/ZX-Spectrum-relaunch-gaming-goes-back-to-the-future.html Lots of you have probably already heard this, but I don't remember it being mentioned, so thought I would! ;-) Supposedly a company were going to relaunch the zx spectrum this year (by the looks of it, as a 48k speccy keyboard that links up to an iPhone or similar to run an emulator), to coincide with the 30th anniversary, but it doesn't look like it's going to materialise any time soon. I know something similar is/was being planned for the C64? However, it got me thinking... Obviously in this day and age, many of use want to enjoy the retro gaming experience, but we haven't exactly got the space to keep things set up. I intend to have my SAM set up permanently at some point, but I very much doubt I'd ever get the space to dedicate to other systems, so clearly something that pleasantly replicates the original experience quickly and easily with modern advantages would be a pleasing alternative. So I figured, what would make an easy to use 'spectrum' emulator for playing all the old games? You'd want HDMI output for ease with modern televisions, SD card storage, and have it all fit into one of our old rubber keyed friends. How do you do this on a budget at that size? The first thing that popped into my head, is the Raspberry Pi (if it ever gets to selling!!). Small enough to probably fit in a speccy case, with HDMI out and card reader. Surely
Re: ZX Spectrum 'relaunch'
I'm hoping a Raspberry Pi, USB CF reader and SimCoupe will pretty much satisfy that, if it runs fast enough. If the CF card is just for Atom Lite use, you'd probably be better off with a an HDF image on the boot SD. Or if you want to share with a desktop machine, maybe a low-profile USB stick instead. Si On 13/04/2012 21:55, James R Curry wrote: Find me a hardware solution (Spectrum OR SAM) that'll allow me to run on a modern TV (or monitor), use Compact Flash, has perfect (or near perfect) compatibility and which isn't going to be hard work or very costly to obtain and receive here in the USA. I'll buy it tomorrow if you find me that. -- James R Curry On Apr 13, 2012, at 3:37 PM, Thomas Harte tomh.retros...@gmail.com wrote: For the purposes of debate, I think the counterargument would be that a software approach is inherently more portable and so more maintainable and more suited to a wide audience. Furthermore, there's no automatic advantage to doing things in hardware, given that these systems are fully deterministic and well understood, other than that it can be easier to get right, but that's primarily because the emulation mindset doesn't normally consider absolute accuracy to be a paramount concern. That's why you very often see people write emulators where interrupt timing is rounded to the nearest whole instruction, palette changes are accurate only to the nearest whole scan line, etc. Authors often prefer to make a subjective judgment about what's 'accurate enough' so that they can prioritise ease of development and/or performance. Summary then: emulation carries no inherent accuracy penalty. Alternatively, as a person who prefers functionality, surely you can see the benefit in emulation, which is all functionality and no form? The hardware becomes a completely orthogonal issue. On 13 April 2012 11:32, Aleš Keprt a...@keprt.cz wrote: I don't share your thoughts. There already exist a lot of Spectrum clones based on real ULAs and real Z80 and imo these are much better alternatives than what you described. You can already buy anything you can imagine. So many alternatives already exist and were created by huge fan base in the past, that I can hardly imagine that somebody can really come today driven by just marketing or business visions and create something significantly better or more compatible or more useful. For example: I personally prefer functionality, not the look of that crappy original keyboard. So I would prefer a PC keyboard, CF memory card instead of tapes or disks, and real ULA (i.e. 100% accurate ULA clone), standard 128 KB RAM, and real Z80 CPU. For other people who prefer or require the original ZX Spectrum case, they can buy a new internals - this was already possible to buy 10 or more years ago. (I personally has a working original ZX Spectrum+ and working original Sam Coupe. :-)) I think you are too focused on emulators - why would anybody put a today's computer with an emulator inside an old ZXS box? It's just funny, not worthy. I prefer either emulator on a proper PC computer, or original 8bit Zilog Z80 in an original box. :-)) Aley -Původní zpráva- From: war...@wdlee.co.uk Sent: Friday, April 13, 2012 12:18 PM To: sam-users@nvg.ntnu.no Subject: ZX Spectrum 'relaunch' Off on a bit of a non-SAM tangent (but probably somewhat related for most of us) I came across this the other day: http://www.telegraph.co.uk/technology/video-games/8304237/ZX-Spectrum-relaunch-gaming-goes-back-to-the-future.html Lots of you have probably already heard this, but I don't remember it being mentioned, so thought I would! ;-) Supposedly a company were going to relaunch the zx spectrum this year (by the looks of it, as a 48k speccy keyboard that links up to an iPhone or similar to run an emulator), to coincide with the 30th anniversary, but it doesn't look like it's going to materialise any time soon. I know something similar is/was being planned for the C64? However, it got me thinking... Obviously in this day and age, many of use want to enjoy the retro gaming experience, but we haven't exactly got the space to keep things set up. I intend to have my SAM set up permanently at some point, but I very much doubt I'd ever get the space to dedicate to other systems, so clearly something that pleasantly replicates the original experience quickly and easily with modern advantages would be a pleasing alternative. So I figured, what would make an easy to use 'spectrum' emulator for playing all the old games? You'd want HDMI output for ease with modern televisions, SD card storage, and have it all fit into one of our old rubber keyed friends. How do you do this on a budget at that size? The first thing that popped into my head, is the Raspberry Pi (if it ever gets to selling!!). Small enough to probably fit in a speccy case, with HDMI out and card reader. Surely this could make for a fairly
Re: SAM HAM viewer
On 12/04/2012 23:34, Simon Cooke wrote: Btw... I think the link to the dsk is busted right now... Oops, yes -- fixed now! :) It's possible the broken redirect is cached, so try: http://simonowen.com/sam/shamview/shamview.dsk?x Si
Re: SAM HAM viewer
On 11/04/2012 22:42, Stefan Drissen wrote: Is the palette being adjusted multiple times while the line is being drawn (similar to the rainbow processor effects on the Spectrum) No, only outside the image being drawn, for now. how many t-states are available between line end and next line start There's only 128T for updates in the horizontal border, which is just enough time for 6 updates if positioned correctly. The update OUTI is 24T in the border area and 32T over the main screen, including memory and I/O contention. Even with an unrolled OUTI loop there's still only time to update 13 entries across a full scanline. I did consider using external RAM for the viewer, but it'd probably only allow 1 extra update, so wasn't really worth restricting the hardware it would run on. interested in would I be able to increase the sample rate from 10.4 KHz to 15.6 KHz? Or is the gain from uncontended vs contended RAM much too small? I'm not sure it'd be enough. If you can extract+modify the relevant code snippet it shouldn't be too difficult to check in the SimCoupe debugger... Si
Re: Junk mail
On 4 Apr 2012, at 23:54, Andrew Collier wrote: I fear it might be some kind of attempt at reprisal for me blocking his worldofsam account due to his spamming and abusing other users, so apologies to anyone who is getting affected by the crossfire. I've received the same e-mail with 157 attachments at least 7 times over the last year or so. He's got a growing list of victims too, and I counted 90 addresses in the latest assault. I've tried reasoning with him, GMail abuse reports, and simply ignoring him. Nothing works, and the junk keeps coming. Si
Re: SAM HAM viewer
On 2 Apr 2012, at 02:05, Aleš Keprt wrote:
So how many colours are possible per line in this format? Or what is possible
in this picture format?
The number of colour changes per line depends on the image width, as CLUT
changes are only made outside the image. That gives 6 dynamic and 10 static
for full 256-pixel width, but up to 11 dynamic and 4 static for 96-pixel narrow
images.
Also, I think that the converter could possibly de-noise the picture before
or after the conversion.
Most of the conversion is using traditional methods — Heckbert's median cut to
reduce to the full SAM palette, then Floyd-Steinberg dithering to apply it.
The result of that will be close to what you'd get converting it in a typical
desktop image-editing package. Of course, there's a second step conversion to
reduce to the CLUT size, but it aims to keep the image as close to the original
converted image as possible. Reducing the dithering ('noise') would mean
compromising on pure colours, which is something that should probably be done
interactively on a per-picture basis.
The viewer is quite straighforward, all the colour magic lies in the
converter.
The core viewer code is short, but there's more to it than meets the eye! The
start alignment and dynamic colour count depends on the width of the image
being viewed. There are 6 self-modifying points used to inline counters and
pointers, since there's little time to make decisions at runtime.
The converter is still very important, of course, and my proof-of-concept
script has certain deficiencies. I'm hoping that having a released native
viewer will mean it can be included as an output format in existing SAM image
conversion utilities, where the conversion will get the extra attention it
needs, and by someone that knows more what they're doing!
Si
Re: SAM HAM viewer
On 2 Apr 2012, at 23:58, Thomas Harte wrote: I think that used a tight loop of something like (i) load next palette index, next colour and next delay length; (ii) push colour to palette index; (iii) perform a busy loop of the desired length; (iv) repeat. That's closer the approach I was originally aiming for, but the conversion is far more complicated. For a first attempt I restricted it to changing the CLUT when the raster was outside the image, which still gives a noticeable improvement over a static palette. My ideal approach would even eliminate steps (i) and (iii), and just use a huge unrolled loop of OUTI instructions. That would update 1 CLUT entry per instruction in reverse order, in a continuous loop. The converter would be tracking a rolling window colours, with knowledge of colours no longer needed and look-ahead to what can be set up in advance. It also needs to understand the instruction timing, which varies across the scanline. Thinking of implementing that still makes my head hurt! but you could instead, say, change a single palette index several times over the course of a single scan line, or anything in between. I considered individual CLUT updates for my current viewer, but it took too much time away from the actual updating — the extra LD B,n needed costs about the same has half an OUTI. Instead I grouped the dynamic colours together and updated them with a small unrolled OUTI block. If you have portions of the image with only four colours (especially once the colour aliasing forced by the 128-colour palette is accounted for) then switching to mode 3 for a portion of a line could be the smarter thing to do, and would presumably cost basically nothing to implement? Unless you need the extra resolution, I don't think there's anything to gain from using mode 3. It uses a subset of the mode 4 CLUT, so it doesn't help with fast access to an alternative colour set. Or am I missing something? Si
Re: ASCD 0.98 WIP 2 released
On 28/03/2012 19:27, Aleš Keprt wrote: My final choice is Microsoft ADPCM, its bitrate is 384 kbps (for 48kHz stereo), i.e. 172 MB per hour, and I think the audio quality is good. I tried ADPCM for SimCoupe but wasn't very happy with it. MS-ADPCM was brighter than IMA-ADPCM, but still seemed to have too much extra noise and swooshiness (for want of a better word!). It will depend on what you're recording too. Spot effect and pure notes are probably fine, but it struggled with rapid note changes in some music. My early recordings were of Manic Miner, and it was the in-game music that put me off. Here are some samples, including PCM and ADPCM variations: http://simonowen.com/misc/sndcompare.zip (661K) The ADPCM versions seem quite inconsistent, as the quantisation size vary between blocks. I actually prefer the constant quality of the 22kHz 8-bit PCM instead. Again, it depends what you plan to do with the recordings. Chances are they're just uploaded to YouTube, where they video will usually suffer more than the audio (~128kbps AAC) in transcoding. I'm sticking with PCM for now, with an option to vary the quality. MS-RLE has served me well on the video side, and is widely supported. Si
Re: ASCD 0.98 WIP 2 released
On 30/03/2012 21:15, Aleš Keprt wrote: I think the audio track needs to be compressed to MP3 in an external program. MP3 would have been good, though I don't know if finding a legal free codec for the encoding might be a problem? The demo AVI I posted a few years ago was run through VirtualDub to convert the audio to MP3, so it was a reasonable size for my website. My original plan was to record to a lossless file, and let the user transcode to their preferred video+audio format. In practice, I can't imagine many people will bother with that, so cutting the original video size is better. Finding the right balance between size and quality is the tricky part. Another issue I had was sticking to simple formats for speed, and so I could implement them directly in SimCoupe, to reduce dependencies on different platforms. Decent audio encoders certainly weren't trivial! MRLE is an big unknown to me. Unfortunately VirtualDub cannot write MRLE files so I did't do any tests with it. I think Microsoft dropped the MRLE encoder in newer versions of Windows, maybe after XP. I think VirtualDub is completely dependent on local codecs for output too. You could probably use ffmpeg to output MRLE under Windows, if you wanted to compare. A friend sent me his test video in MRLE he recorded in another ZXS emulator and it is quite small, but it is really new thing for me. I remembered finding that RealSpectrum videos were small, and I found it was using MRLE for lossless video. I researched that and found it was surprisingly simple. When we compared MRLE to SCLS, the MRLE file was 6x bigger. I hadn't heard of SCLS before, but it does sound like it works better than MRLE. Perhaps some of the size difference is that I force keyframes every second, to improve seeking resolution? Audio still takes up the bulk of the video size, so there's probably more to be gained on that side. FLAC would have been nice :) Si
Re: ASCD 0.98 WIP 2 released
On 30/03/2012 22:01, Aleš Keprt wrote: So you use your own MRLE encoder instead of Microsoft's codec? How does it work? Yes, the MRLE encoder is fairly simple, and probably under 100 lines of code. The audio data is exactly what's written to the sound card buffer, so that didn't need encoding. The AVI file is just a structured RIFF file, which I write directly. Ironically, I spent more time getting the RIFF headers correct than actually implementing the video encoder! Sources disagreed on some values, and most players were very forgiving, so it wasn't easy to tell when something was wrong. AFAIK lossless audio codecs aren't technically possible in ACM. I'm not sure if I've seen an ACM codec for FLAC that supports encoding, which might be the main problem. I've never used the ACM API myself so I'm not sure if there are any other issues. FLAC works well for lossless audio, but the data might still be 1/3 to 1/2 of the original PCM audio size. A quality lossy codec would do a better job, but would be more demanding for encoding during emulation. IMO the best option for audio would be to save the SAA register values. I mean the best i.e. the smallest file size. That would make very short files, but nobody would replay those files outside our custom player. In theory you could write an ACM decoder to support the new audio format, which generates 1 frame worth of PCM from the SAA registers! Probably not worthwhile, and you'd still miss out on the DAC outputs. Si
SAM HAM viewer
Hi all, I've been experimenting with HAM-style tricks on SAM, to try to improve the quality of converted images. I've aimed to modify as many colours as possible between lines, rather than using the traditional compromise static palette. Are there any viewers using that technique already? I've written a Python script to convert regular images to a new .sham format, and a SAM viewer program to display them. Demo: http://simonowen.com/sam/shamview/shamview.dsk Source code: https://github.com/simonowen/shamview You might recognise some of them as SAM or image processing favourites! It still needs work on the dynamic palette selection, which just uses the most-frequent colours, rather than doing proper quantisation. I left the crayons image as an example of this breaking down. Si
Re: Emulation etc...
Previously I wrote: It should still be possible to add a USB sound device, at the cost of one USB port. Hopefully not too much extra latency either. I've just tested this out with my HP Microserver Linux box, which also lacks sound hardware. I had a USB sound device that came with my Sennheiser headset, which I don't normally use with my PC. I just plugged the USB widget in, fired up SimCoupe over a remote X session and it ran fine with sound (new sound-sync code too). No noticeable difference in latency either. On 17/02/2012 20:27, da...@properbastard.co.uk wrote: Perhaps it's possible to emulate a simulated accelerated SAM then :) There will be choice of running speed, though it'll still be 6MHz from SAM's point of view. True acceleration would break any time-critical effects, and ASIC contention would eat much of the extra speed anyway. Si
Re: Emulation etc...
On 17/02/2012 20:27, da...@properbastard.co.uk wrote: would it be possible for the raspberry pi to run SimCoupe ... I'd expect the OpenGL SDL version should build and run on it without any trouble. I'll certainly give it a whirl once I get one. My only concern is the sound hardware on the board. I think the chipset supports audio decoding for output over HDMI, but it might only cover media player type use, and is probably not seen as a sound card. Anyone know any more? It should still be possible to add a USB sound device, at the cost of one USB port. Hopefully not too much extra latency either. what sort of speed when compared to the real machine? I'd hope it could run at full speed, given it could (just) manage it on the ARMv5 (well, XScale) chip in my 10 year old Pocket PC device! Si
Re: Coming back to haunt
On 15 Feb 2012, at 13:48, Dave wrote: Here's a fun clip from the first show at Gloucester. So long ago I don't remember what year it was, but it must've been something like '93/94. Fantastic! A lot of familiar faces, and some others I can guess from context (maybe watching with sound would help too). I don't think I went to that particular show, though some of the stands do seem to be in the same places I remember — perhaps they always were? Si
Re: GitHub and a polygon filling routine
On 10 Feb 2012, at 00:10, Thomas Harte wrote: started dumping a whole bunch of my old projects onto GitHub Spookily enough, I started dumping some of my SAM+Speccy projects on there a few days ago! I also added the SAM ROM source, which was converted to pyz80/Comet format, corrected to match the 3.0 binary, and split using the filenames mentioned throughout the original source. Everything is under https://github.com/simonowen as a kind of free backup. Mine was mostly being lazy, so I don't have to managing separate source archives for each binary release. That means that you can now find almost exactly the same 3d engine as I released previously at http://github.com/TomHarte/Sam-Coupe-3d Thanks for that, I'll take a look over the weekend :) Si
Re: Single pixel hardware scroll?
On 2 Feb 2012, at 10:24, Geoff Winkless wrote: If you're thinking of playing with stuff like that in SimCoupé, how about adding in a screen start address OUT mod? I'd love to see what could have been done with just a small change to the ASIC design :) I was drawn by the possibility of there being something new and unimplemented, though it's sounding increasingly unlikely. Still, I think your suggestion should be relatively easy to try, just for fun! Just a single byte offset for the start address? How should wrapping be handled? I'm in the middle of a sound revamp at the moment, but I'll put it on the list to take a quick look after that. Si
Re: Single pixel hardware scroll?
On 2 Feb 2012, at 10:43, Thomas Harte wrote: emulator authors tend to be quite parochial and superstitious about this stuff for some reason, hence e.g. the mostly invented black scan lines a lot of them like to insert. I find a partial scanline effect helps soften a harsh pixelated image, and reduce the softness of the filtering done during stretching with some video drivers. So even if they're not technically accurate I find it somehow looks a bit more balanced than the pure image. There's probably also an aspect that it makes it look more generated, which fits with the feel of being emulated — so you're probably right! Si
Re: Single pixel hardware scroll?
On 2 Feb 2012, at 10:24, Geoff Winkless wrote: how about adding in a screen start address OUT mod? Would that be possible with a real SAM peripheral? Can the value on the bus be changed to redirect the display read? Or is it possible to modify the value read instead? Perhaps something that watched for display reads and cached the values, so it could supply a remapped value to offset the display? Si (software guy with very little hardware knowledge)
Re: Single pixel hardware scroll?
On 2 Feb 2012, at 11:50, Geoff Winkless wrote: If you could just change that 15-bit offset to start at XhXl using The emulation side doesn't keep it as a pure offset, but from what I remember it should still be relatively easy. There might be some funky side-effects for attributes in mode 1, of course. a) tell the difference between a normal address request and an ASIC request The display accesses are in a fixed pattern and offset from the start of the frame, so I'd hope they could be singled out (still assuming they can be seen and overridden). It would also mean tracking the current display mode to make adjustments for the layout differences. Mmm, sounds like it's getting complicated and expensive already. I don't even think the ASIC memory requests appear on the bus, do they? Colin would know :) Beats me :) Si
Re: Single pixel hardware scroll?
On 01/02/2012 20:07, Thomas Harte wrote: I notice that whatever effect it thinks it is relying on doesn't work in Sim Coupe. It's certainly nothing that's implemented at the moment, but if it's shown to be a real effect (like border pixels), it should go in. Though it does feel like it could be specific to CRTs, and more likely those that suffer from distortion due to intensity differences? I remember there being some sample interlaced SAM pictures, which may have relied on the effect to give the necessary vertical shift to help with colour blending. I don't know if the Gigascreen images on the Spectrum rely on something similar. Emulator support for that gave a misleading impression of how they looked on real hardware, where the real images were still quite flickery! Si
Re: New Game - Dave Invaders
Great job with your game, especially as a first in Z80! As well as Manic Miner I got a hint of Jasper from it for some reason. I'm also a fan of the sideways screen wipe, which feels very arcade retro. I didn't notice any issues with the collision detection, though I did struggle to spot the items at times. Looking forwards to what you have in store for future projects :) Si On 27/01/2012 13:49, Andrew Gillen wrote: Hi folks I've finished writing my first game for the SAM. In fact it is pretty much the first game I've ever programmed in assembler (certainly on the SAM anyway) . I've tinkered with various high level languages over the years but have nothing to show for it. You can grab it from this rather minimalist website: http://www.joua.net/ You need a 512KB SAM for it (although when playing it you'd be forgiven for asking why..). Just a run of the mill single screen platfomer, really, but I appreciate any feed back. I've learned a heck of a lot of the year programming it and should be taking the experience gained to improve my skills (what skills?!) when tackling new projects which will be forthcoming! If you find the frame rate somewhat lacking on some levels then you can turn off the music (e-tracker mods) to gain some processing time. Or just turn it off anyway of course if you don't like it! Anyway, enjoy. Cheers Andrew.
Re: SimCoupe Speed
Yes, you could certainly fill the top 32K with faster external RAM. Though using Spectrum-compatible mode 1 does add extra contention stripes, so you'll still get an extra hit on accesses in the bottom 32K. The current SDL version of SimCoupe uses 2048 samples, so it must have been what I found as the best behaving too! Though I've always found SDL sound more awkward to work with as it requests extra data as needed, rather than providing a method to check the level and add more. I'm expecting to use a mix of time stamps and buffer requests to trigger the next frame at the right point, which should solve the 22-syncs issue you mention. It's a lot easier with DirectSound as you have tighter control over the play+write cursors, so you automatically get sub-frame accuracy (or you certainly used to – I've not checked with Vista or later). I have an occasionally worked on source branch that's moving towards doing that, though there are a number of related complications to untangle first. One day... Si On 25 Oct 2011, at 13:18, Thomas Harte wrote: I think I'm right to say that external RAM can be paged into the top 32kb of address space. And it's presumably uncontended? So you could page some in and run a 48 emulator but everything would run at quite the wrong speed. Simon: I've always found 2048 samples to be the sort of level where most operating systems start playing nice with audio output; assuming 44100Hz output, wouldn't synchronising to that limit you to only about 22 synchronisation points a second? So frames would end up bunched together? Not really on topic, I admit, and the evidence that you know what you're doing is plentiful. I'm just curious. On Tue, Oct 25, 2011 at 12:38 PM, Roger Jowett rogerjow...@gmail.com wrote: key repeats? is it impossible to run 48 emulator snapshots in external ram? On 24 October 2011 14:35, Simon Owen simon.o...@simcoupe.org wrote: Hi Ian, I'm hoping fixed running rates will come 'for free' as part of the switch to audio-based synchronisation (rather than the current timer method). In the meantime, if you don't actually need the key repeats, try this patched ROM to disable them: http://dl.dropbox.com/u/2553707/norepeat.zip Extract it somewhere, then select it from Tools - Options - System (tab) - ROM image. Reset the emulated machine to activate it. Cheers, Si On 23 Oct 2011, at 10:33, Ian Spencer wrote: Hi Si, I'm sure you have been asked this hundreds of times before so I'll apologise before I start but I've always used SIMCOUPE synchronised to 50Hz with most programs and with others unsynchronised where the speed was useful (especially with the program which I have used for years to handle my bank accounts) and set the keyboard repeat rate to prevent multiple key presses being produced. But the modern 3Ghz 4CPU machines I now have are just so fast it's impossible to set the repeat rate low enough. They are just too fast and as many programs are much more usable when the speed is 200 - 500% above the standard it would be really fantastic if this was in some way selectable even if at this speed the instruction timings weren't very accurately scaled. Best wishes, Ian Spencer
Re: SimCoupe Speed
Hi Ian, I'm hoping fixed running rates will come 'for free' as part of the switch to audio-based synchronisation (rather than the current timer method). In the meantime, if you don't actually need the key repeats, try this patched ROM to disable them: http://dl.dropbox.com/u/2553707/norepeat.zip Extract it somewhere, then select it from Tools - Options - System (tab) - ROM image. Reset the emulated machine to activate it. Cheers, Si On 23 Oct 2011, at 10:33, Ian Spencer wrote: Hi Si, I'm sure you have been asked this hundreds of times before so I'll apologise before I start but I've always used SIMCOUPE synchronised to 50Hz with most programs and with others unsynchronised where the speed was useful (especially with the program which I have used for years to handle my bank accounts) and set the keyboard repeat rate to prevent multiple key presses being produced. But the modern 3Ghz 4CPU machines I now have are just so fast it's impossible to set the repeat rate low enough. They are just too fast and as many programs are much more usable when the speed is 200 - 500% above the standard it would be really fantastic if this was in some way selectable even if at this speed the instruction timings weren't very accurately scaled. Best wishes, Ian Spencer
Re: Atom CF card under Linux
On 16 Oct 2011, at 15:03, ellvis wrote: Results were that I got only half of the directory visible and after any file load I've got 108 End of file and the data were just mess. MGT (old-style DSK) uses a track order of: c0h0, c0h1, c1h0, c1h1, c2h0, ... BDOS records and SAD images use: c0h0, c1h0, c2h0, c3h0, c4h0, ... So you'll need to re-order the tracks before you can treat them as raw images. Without that you'll see the 1st and 3rd tracks in the directory listing, but the rest of the image will be mostly garbled. You could add this fixed 22-byte header to the extracted data to make them valid SAD images: 41 6C 65 79 27 73 20 64 69 73 6B 20 62 61 63 6B 75 70 02 50 0A 08 Or mount the BDOS image in SimCoupe and copy the record out to a floppy disk image. There will be Linux and Mac builds of SAMdisk at some point too, as the real HDD device code is mostly done. Si
Re: Resistor R55
Hopefully we understand the behaviour of the current ASIC well enough for someone to create a replacement, or (as you're suggesting) and enhanced version that is backwards compatible. It's not a small task though! I have a bunch of test programs that Dave and I wrote for SimCoupe, which tested tested various fringe cases and display quirks. It'd be cool for those to contribute back to real hardware :) Si On 8 Oct 2011, at 15:03, VELESOFT wrote: Hi. My project is SAM COUPE clone (but no ASIC replacement). First prototype will based on big CPLD + fast Z80cpu + big sram + saa1099 sound chip. Here is components for first SAM clone: http://velesoft.speccy.cz/other/ula-xc95288xl.jpg http://velesoft.speccy.cz/IMGP3176.JPG http://velesoft.speccy.cz/IMGP3178.JPG Priorities: - compatibility with SAM COUPE - more colours (minimal 256 colors palette) - faster CPU - possibility run at full speed 6MHz in all graphic modes (not contended memory) - better compatibility with ZX Spectrum (ZX mode can work as ZX128) - big ram + big rom - internal peripherals... Actuallly I must finish ZX projects: K-MOUSE 2011, complette RGBVGA convertor, ULA1 clone (zx clone based on old russian chil ULA1). After it I can continue on SAM projects... VELESOFT
Re: Accessing Sam formatted disks through a USB floppy drive
Thomas Harte tomh.retros...@gmail.com wrote: my USB floppy drive showed up as a block device and exposed only the PC-style double density sectors as blocks. That's just how USB floppy drives are seen by the system, and is the reason they're so limited. The LBA to CHS mapping is internal to the drive unit, so you're stuck with 9-sector access for DD disks. There's no way to work around it by changing OS or disk utility. That said, I did hear about there being some USB floppy unit that supported a non-standard request to change the mapping. That would be enough to access normal format SAM disks, but nothing much more exotic. I'm not aware of any programs that attempt to make use of it though. The Kryoflux, at about £80, doesn't actually look like a bad deal, but can I attach a Disciple/+D drive to it? Out of the box you can connect a 3.5 floppy drive to it with a normal floppy cable. You'll also need separate power for the drive, from at AT PSU or similar. I can't remember what the +D cable was like, but there are adapters for 3 drives, so perhaps something could be worked out. It'd certainly be nicer using a powered drive unit in an enclosure. I'll probably get one myself at some point, though more for Amiga use than SAM! On the SAM side I should be able to manage with Atom Lite + CF card, with SDCard HxC floppy emulator for non-standard disks. I'm trying to wean myself of real floppy disks as my next desktop system won't support them. Si
Re: Accessing Sam formatted disks through a USB floppy drive
Dicky Moore wrote: Has anyone had any luck in copying Sam-formatted floppy disks to .dsk or .mgt images using a USB floppy drive? Samdisk doesn’t support USB floppy drives and I’m not sure of any other software that can do this. I'm afraid there's no way to do it with a standard USB floppy drive. It's a hardware limitation without any software work-arounds, so no other program can do it either. You'll either need a desktop PC with an on-board floppy controller, for SAMdisk use, or some special hardware that doesn't need a floppy controller chip (such as Kyroflux), which isn't cheap for one-off use. I’m trying to recover all the E-tracker music I created back in the day. If you don't have access to a PC that can do it, and you can get the disks to me, I can dump them for you. Alternatively, if you still have your real SAM then we can work around the sector 10 issue, using a spare floppy disk to hold a copy of the inaccessible sector 10s. Two 9-sector disks, which can be dumped on a USB drive, could be pieced back together to give the complete MGT 10-sector image. If you're still using your real SAM, you'd perhaps be better off with an Atom Lite board. You can copy your disks on to that very easily, and the Compact Flash card is easy to move back and forth between SAM and PC. SAMdisk can read extract disk images from it (or write them back), or you can use it directly in SimCoupe. If you want to try a SAM-side work-around, drop me an e-mail... Si
Re: Contention and JR instruction timing.
David Brant wrote: Just to put a spanner in the works. JP's are faster in external memory. You're right! External memory is uncontended, so it's as fast as the ROM. SimCoupe does already implement that correctly, so it's just my memory at fault. I ran a test incrementing BC in a tight loop between the end of active frame interrupt and the following interrupt. The counts were: External RAM: 11965 Internal RAM, screen off: 9971 Internal RAM, screen on: 8915 Internal RAM, mode 1: 8028 It seems well worth using if it's present, even if it doesn't help so much with display code. It should give a worthwhile free boost to my various 6502-based emulators though. Si
Re: Contention and JR instruction timing.
Chris Pile wrote: In short, then, I guess I should ignore what Zaks is telling me regarding T-states and simply try to use single/double byte instructions wherever and whenever possible? As a very rough guide, round the official instruction timings up to the next multiple of 4, then double it if executing over the main screen. For a slightly better approximation, start with the official instruction timing. Then add 1T for every memory access (or 5T if executing over the main screen), and subtract 1T from the total. Don't forget to include opcode, operand and data fetches during execution. Alternatively, just single-step real code in SimCoupe to see how long each instruction takes! For anything more accurate you need to look at the instruction timing breakdown of what is happening during each machine cycle. The true total timing is just the sum of the parts, with contention delays added before each RAM (or contended I/O) access. Looking at the JP nn case from http://www.z80.info/z80ins.txt: JP nn = OCF(4) ODL(3) ODH (3) 4T for opcode fetch 3T to read operand data low 3T to read operand data high That gives 10T for the official timing. For the SAM comparison it's simplest if we examine from the same first step up to the same point in the following instruction, rather than starting with the contended opcode fetch: 4T for opcode fetch ?T delay for contended operand RAM access 3T to read the low byte of the operand data ?T delay for contended operand RAM access 3T to read the high byte of the operand data ?T delay for contended opcode RAM access before next opcode With JP nn there are three points where the contention delays are applied. The delay values depend on what the ASIC is doing at the time. It restricts us to 1 access every 4T in the border and 1 access in every 8T over the main screen. This means rounding up the cycle position to multiples of 4T or 8T at each contention point. In the best case for border area execution this gives: 4T for opcode fetch 0T delay (rounding to multiple of 4, nothing needed in this case) 3T to read the low byte of the operand data 1T delay (rounding to multiple of 4) 3T to read the high byte of the operand data 1T delay (rounding to multiple of 4) =12T In the worst case for main screen execution this gives: 4T for opcode fetch 4T delay (rounding to multiple of 8) 3T to read the low byte of the operand data 5T delay (rounding to multiple of 8) 3T to read the high byte of the operand data 5T delay (rounding to multiple of 8) =24T Each delay depends on where it's executed, which prevents there being a definitive list of SAM instruction timings. Long instructions accessing memory have the biggest contention penalty. LD IX,(nn) has 6 contention points, which in the worst case increases the official 20T timing to 48T! In addition to RAM contention there is also I/O contention to consider. SAM ports F8-FF are of interest to the ASIC, so there is 8T rounding applied before each IN/OUT. As with the RAM accesses, this is applied at the point in the instruction where the I/O occurs. It's not as simple as using the official Z80 timings, but you'll soon get a feel for it. For best results, use short instructions and reduce memory accesses by keeping working values in registers. In the border area, many common instructions are close to official timings – 4T single-byte instructions have no additional penalty, and the common 7T instructions only cost an additional 1T. Quick overview: ROM accesses are uncontended, so there are no additional delays. Though any RAM accesses made from ROM code will still be affected, of course. Internal RAM accesses have 4T rounding in the border area, and 8T when the ASIC is fetching display data to draw the main screen. If the display is disabled there's no screen drawing, so 4T rounding applies everywhere. In screen mode 1 there are additional bands of 8T rounding across the entire display, alternating every 64T (see http://simonowen.com/sam/articles/mode1/ for details). External RAM accesses have 4T rounding at all times. I/O on ports F8 to FF have 8T rounding. Clear as mud? Si
Re: Contention and JR instruction timing.
David Brant wrote: Just to put a spanner in the works. JP's are faster in external memory. JR and JP will both be 12T in external memory, which is the same speed as they are in internal RAM during the border area. External RAM gives the same speed boost as disabling the display, by avoiding the slow-down when the main screen is being drawn. JP is only faster than JR in ROM code, where the official Z80 timings apply. Simon Goodwin's fractal viewer makes use of the extra speed in external RAM. Does anything else use it for more than just the extra space? Si
Re: Contention and JR instruction timing.
On 26 Apr 2011, at 10:25, Geoff Winkless wrote: Would it have been better to have 48kB of more expensive display memory, giving only the live display and a secondary (for double-buffering) but losing the ability to use any page in RAM as the screen? snip For me the real mistake, though, was the lack of capability to set the display address counter for instant free hardware scrolling (and for not much electronics, unless I'm missing something) - even the BBC Micro had that in 1982. Just those two could have made a huge difference to what was possible. *sniffs* I do vaguely remember Simon Goodwin explaining why SAM missed out on hardware scrolling, but I can't remember the details. I think it was something RAM access related, so perhaps the change to use dedicated VRAM would have made it easier? As a hardware n00b I've no real idea! Anyone? Apologies, I'm hijacking the thread again. Erm, Hula-hoops: beef or salt-n-vinegar? S'n'V, fo' sho'. Si
Re: Contention and JR instruction timing.
On 26 Apr 2011, at 12:46, Geoff Winkless wrote: On 26 April 2011 10:55, Chris Pile chris.p...@blueyonder.co.uk wrote: Some sort of blitter to chuck large blocks of data around at high speed would have been a *very* nice addition. That 24k screen really is too much for the old Z80 to cope with! Eugh... _another_ thing to add to Simon's memory contention list? :) Yep! A certain someone in the scene considers DMA to be a magic bullet that will solve all SAM's problems, but it'd be fighting for the already limited memory access. My hardware experience is pretty limited though, so I'm not going to start contradicting Mr Goodwin. It's possible the reasons were cost-related too, but I'm sure there was a technical angle. Si
Re: Contention and JR instruction timing.
Hi Chris, The short answer is Yes, it's best to use JR e over JP nn on SAM. In the best-case border area, both are 12T. Fully on the main screen, JR is typically 16T and JP is a whopping 24T. It does depend a little on the starting cycle alignment, and instructions spanning the screen edges are more complicated to work out. In general, shorter instructions mean fewer memory reads, and less memory contention. JP (HL) is as fast as a NOP, at just 4T in the border and 8T on main screen. Si Chris Pile wrote: Just a quick question regarding memory contention on the SAM and its effect on JP and the *unconditional* JR instruction. Z80 timing lists state that JP takes 10 T-States whereas an *unconditional* JR takes some 12 T-States. However, does the SAM's memory contention make all *unconditional* JRs faster (or as fast) as the JP due to the JP needing another memory access? Just a simple Yes, always use JR over JP in unconditional cases - or - No, stick with JP as it's faster! please guys, as my head explodes reading too much hardware-based theory! Cheers... Chris.
Re: Floppy Disks
This is becoming more of an issue, with Macs and newer desktops not having a motherboard floppy controller, and more widespread use of laptops... Almost all USB floppy drives are usually limited to 720K (9-sector) and 1.44M (18-sector) formats. They contain their own floppy controller chip, and the LBA to CHS mapping is done within the unit. Unfortunately that means there's no way to access the 10th sector on regular SAM disks. SimCoupe relies on being able to talk to the floppy controller directly, using my fdrawcmd.sys driver under Windows or the kernel fdrawcmd interface under Linux. I have been thinking about support for USB floppy drives in SimCoupe, working within the 9-sector limitation of USB drives. It would require disks to be prepared for access on a real machine (or using SAMdisk), so SimCoupe can recognise them as special, and to reserve the 10th sector on each track to prevent data being saved there. On the SimCoupe side, the 10th sector in each directory track would be faked as holding the same reserved/hidden files. The disk could then be used as normal on both SAM and SimCoupe sides, but with 702K rather than 780K available for data. Nowadays it's probably easiest to use an Atom Lite interface on the SAM side and share a CF card between SAM and SimCoupe (or indeed a Trinity and SD card). It gives a centralised store of all your work, and avoids the reliability issues with floppy disks – just be sure to back it up periodically in case you lose it! Si On 5 Apr 2011, at 12:19, war...@wdlee.co.uk wrote: Just as a side issue, with regards to Sim Coupe... (sorry for the quick change of topic!) This is probably a daft question, as I think I've read about the issue elsewhere, so forgive me... but is there no way to read/write to external USB floppy drives? Just thinking of my own case, and others are probably similar, where I use my laptop 99.9% of the time these days (and of course modern laptops don't have a built-in floppy drive. Not to mention, there are increasingly fewer desktop systems that include floppy drives these days anyway, so even people using desktops are increasingly likely to find it easier using external plug-in drives. Is it a complete impossibility? ;-)
Re: Floppy Disks
Hi Warren, The enclosure would still only work if the laptop motherboard had a regular floppy controller chip, and I'd be surprised if any have included one in the last 5 years. The actual floppy drives themselves are pretty dumb, so it's all about what you've got them connected to. There are some modern USB-based low-level floppy solutions, designed for software preservation, but they'd be overkill for most SAM use (and cost 50GBP+). I'm a bit fuzzy on the details of the Trinity SD card format, but I think it's pretty much the same BDOS format used by the Atom interfaces (perhaps using Atom Lite byte ordering). I remember there being an issue with some cards not using 512-byte blocks, so it might be best if Colin filled you in on compatibility. Of course, you'll be working with the plain Atom emulation on the SimCoupe side, as it doesn't emulate the Trinity interface. SAMdisk supports BDOS devices too, so you can list, get directory listings of, and copy to/from individual records. If you already have a Trinity-format SD card, try a samdisk list from a command prompt, to see if the media is recognised. If you're on Vista or Win7 you'll need to have launched the command prompt with Administrator rights too, to have permission to open the raw disk devices – the same applies to SimCoupe using them, for now. Si On 5 Apr 2011, at 13:11, war...@wdlee.co.uk wrote: Thanks for the fast reply! :-) I suppose in theory, an internal-type drive in an enclosure would be plausible, but by the time you get to that, and the rarity probably of even enclosures for something like that and the added drivers, it defeats the purpose. Oh well... Worth finding out! ;-) On an alternate route, I wonder if Colin could create a small PC program that would allow transferral of .dsk files to the allocated slots on a Trinity formatted SD card? Though again, I have no idea how plausible, as it would depend on the way the Trinity formats and stores things on the SD card. Obviously it wouldn't make sense to have Sim Coupe emulate the Trinity, as the point is to have a device that people want to buy because it allows their SAM to do something they can't possibly emulate. But a .dsk transfer utility to and maybe from the Trinity SD cards might be useful? Just thinking out loud! ;-) Then again, a completely nutty route... Since the Trinity will very possibly have FTP at some point, file transfer could be done in a round about way, by uploading or downloading files lol! So in theory, if you don't have a handy built-in floppy drive, you could develop in Sim Coupe, upload to your website, and then download to the Trinity. Sorry Colin, my ponderings are jumping all over the place lol! ;-) Quoting Leszek Chmielewski retr...@gmail.com: The USB Floppys have a extremly cut down controller which is missing ability for low level access. So the answer is no. My Acer TM312T has a external parallel port Disc drive, and it can read and write Coupé Discs, only because the BIOS. It would be possible to make a USB Floppy which can use SAM discs, but not in a standard way. And it would also need new drivers. 2011/4/5 war...@wdlee.co.uk Just as a side issue, with regards to Sim Coupe... (sorry for the quick change of topic!) This is probably a daft question, as I think I've read about the issue elsewhere, so forgive me... but is there no way to read/write to external USB floppy drives? Just thinking of my own case, and others are probably similar, where I use my laptop 99.9% of the time these days (and of course modern laptops don't have a built-in floppy drive. Not to mention, there are increasingly fewer desktop systems that include floppy drives these days anyway, so even people using desktops are increasingly likely to find it easier using external plug-in drives. Is it a complete impossibility? ;-) Quoting Simon Owen simon.o...@simcoupe.org: On 4 Apr 2011, at 16:02, Simon Cooke wrote: If SimCoupe uses rdtsc without setting the CPU thread affinity, there are issues on some systems where it loses track when the thread is scheduled onto another CPU core. Usually a bios update can fix this, or switching to use QueryPerformanceCounter. It did use QPC, but only for sub-system profiling within the emulator. That was becoming increasingly meaningless with multi-core systems, so I stripped it out a couple of months back! Knowing the running speed and the framerate should be more than enough for most users. I remember taking special care of the issue in my floppy driver, where even kernel QPC could use up using different timestamps on some systems
Re: Introduction and E-Tracker Query
On 3 Apr 2011, at 23:26, Andrew Gillen wrote: All development and composing has been on Sim Coupe so far. The guy doing the music has redone the module from scratch, and made it a lot longer. This time round most of it plays fine until about 40 seconds in when some of the channels come in at the wrong time and are all messed up. If you suspect that there could be a SimCoupe issue, please do send it my way. I'd be surprised if a CPU core issue would have gone unnoticed for so long, though it could still be some other time-sensitive aspect of the consistency of the emulation – such as input updates being applied at the same point in each frame. Si
Re: OT CP/M + Locoscript
Hi Nev, If it's not too many disks I'll offer my services to dump them for you. I've got a 3 drive with a PC adapter and SAMdisk will dump them to a suitable format. Or you're welcome to borrow my hardware and do it yourself, depending on how sensitive the contents of the disks are. The output images can then be used in a Spectrum emulator or with Pro-Dos in SimCoupe, or just written back to a 3.5 disks if that's of any more use. Best regards, Si On 7 Aug 2010, at 12:51, nev young wrote: Hi Steve, Thanks for the follow-up. Unfortunately, he has had some setbacks and hasn't been able to get back to me yet with any disks to try it out yet. As I start a new job, away from home, on the 16th it looks like this may get kicked into limbo until next year. We don't believe in rushing stuff here in Norfolk :-) Meanwhile I'm searching through all my back issues of Format to find the details of the fixer so I can connect one of my Plus-D to a Spectrum +3 to transfer data from 3 to 3.5 disks. I really must learn not to offer to do favours. Nev On 05/08/10 20:47, Steve Parry-Thomas wrote: How did your mate get on Nev? Did he get his data/disk images ?
Re: Debugging - argh
On 19 Jul 2010, at 22:47, Stefan Drissen wrote: Now hurry along Si and integrate the label.tab in SimIce… ;-) If it's just symbols you want tied in, I'm sure that can be arranged :) You may want to ask David to add page information to the label.tab file first though. ;-) Speaking of paging... it may be a good time to ask about how best to deal with addresses in the debugger. The data import/export has always suffered from the complications of the current 64K paged setup, BASIC addresses and raw page+offset for both internal and external RAM. For the debugger I started down the path of allowing a mix of plain addresses (0-65535, for 64K paged) and absolute (p:o for page+offset). Disassembling generally only makes sense for the current 64K, but data views could let you to browse through the whole of RAM. Whichever mode you started in would determine the extent and wrapping of the viewed block. Worth finishing, or is that overcomplicating it? I originally wanted to have a command-line interface, much like the Soft-ICE debugger. It ended up being a bit more like TurboMON, which was influenced by the Multiface single-key commands. The current method is fairly quick to get around, but requires learning more key combinations. A command-line would be ultimately more flexible, but require a little extra typing. Anyone got a preference? If you have any other thoughts on what should be added or changed, I'm open to suggestions. It got left a bit unfinished when I could do what I needed from it to debug SimCoupe itself, but if there are more people using it then it's more likely to be worked on. I've not been around much recently for any home development stuff, but scene activity is always good to help draw me back in! Si
Re: New SAM emulator for Windows
Adrian Brown wrote: If its emulating the SID then id be worried about copyright. The SID interface is a current piece of hardware and as far as im aware there has been no rights granted to emulator its ability. Technically, it's just a SID chip connected to the expansion port, so what is there to copyright? If Jarek or Edwin made their own SID board, would emulating theirs be fine? Or would you consider that stealing the design from Colin? I have an agreement with Colin about not emulating Quazar devices. It's not that I feel there's a legal issue in doing so, but out of respect for his wishes. Colin is aware my version of SimCoupe has supported the SID interface for sometime, as it helped me develop and debug my SID Player. Whether that makes it into a released version is still undecided, for the reasons above. Si
Re: Fully detailed instruction timing breakdown?
Andrew Collier wrote: He didn't include code, but he described counting the number of NOP instructions executed between two consecutive frame interrupts. I've knocked up my own version, which uses the block of NOPs, but with a DEC A ; JP Z at the start to exit once the test is complete. They add 16T, which is the same as the 4 NOPs they replaced. There's also an EI a little later to re-enable interrupts when they're no longer active. The value I get in SimCoupe is 119792, which is 16T short of the expected full frame time. The difference is about what a contended push PC and jump to IM1 handler would be (as you mentioned below). I'll check it's the same on the real machine tonight. Code and bootable disk are here: http://obo.homeip.net/frame_time.zip Although, thinking about it now, somewhere in this experiment you'll need to account for the time it takes to the Z80 to find its interrupt routine and to stack the PC. Does that take as much as 112 t-states? It's definitely too much to be just the handler overhead. It's suspiciously close to the 128T active interrupt period, so perhaps interrupts were enabled too soon for the next one? If only the last value on the stack was used, it'd be short by the amount it was held back due to re-triggering (approx 112-128T?). Is this simply a question of notation? Where an instruction waits several t-states before starting (presumably because of when the ASIC allows memory access for the instruction fetch) I would normally have counted that as part of the first instruction, whereas your examples are counting it in the second. It does make sense to do that for coding notation, where the delays balance out. My timings were from a strict execution point of view - from the current cycle to the cycle after the instruction completes. Perhaps it does only matter to SimCoupe, which always needs to know the true picture. For instance, including the delay from the following instruction could affect whether an interrupt is accepted after the current instruction completes. So in your final example, I would have expected an instruction following that sequence to start 40T after the first ret nz did - each instruction having started at intervals of 8T. Is this not the case? You're right - 37T rounds up to 40T, so I must have added them up wrong last night! I definitely remember cases sensitive to the ending alignment, but perhaps it was only for longer instructions that were stretched by contention delays. Or maybe one of the more contrived cases Dave and I created for testing. I'll see what I can dig up... Si
Re: Fully detailed instruction timing breakdown?
Simon Owen wrote: The value I get in SimCoupe is 119792 I'll check it's the same on the real machine tonight. Same same. Si
Re: Fully detailed instruction timing breakdown?
Simon Cooke wrote: I was wondering… does anyone have a fully-detailed breakdown of instruction timings for the SAM? Including at various points in the screen? It's hard to have a complete list for anything but the smallest instructions. For longer instructions it depends on how they fall inside, outside or across the contention boundaries, and which memory and I/O locations they access. Internal RAM accesses are rounded to 4T in the border area, or when the display is disabled. They're rounded to 8T when the ASIC is fetching data for the main screen, which begins an 8-pixel block before the main display area. Screen mode 1 adds additional bands of contention, with more 8T rounding (details on my website). External RAM accesses are always rounded to 4T, and ROM accesses are completely uncontended (no rounding). I/O accesses involving the ASIC (ports F8 and above) are rounded to 8T, other ports should be 4T rounded. The total timings for an instruction need to be built up one machine cycle at a time, with the appropriate memory and I/O rounding added, depending on where the raster is. It sounds messy, but it shouldn't be too bad since you'll only have a few fixed fragments of code for the palette changing. I can help you work out the instruction timing breakdown once you've decided on the code fragments to use... The idea is that it’d generate code to change the palette as the screen renders, and adjust the bitmap to get the closest it could to the original source. I was talking about that with someone a year or so ago (Edwin maybe?). Though it was only for a simplified version to change a few palette colours during the border area of each scanline. Your version would be much more effective, but is also far more complicated! Perhaps LCD would be interested in this too? His Retro-X application does a great job with the limited standard palette, so a dynamic palette should be even more impressive. Si
Re: Fully detailed instruction timing breakdown?
Andrew Collier wrote: I think the only question it doesn't answer is what happens to the 112 t-state difference between the number of t-states measured with the screen off (119696) and the number that would be expected from the timing characteristics of the screen display (119808). Doesn't that just mean the real SAM framerate is ~50.08Hz instead of 50Hz? That's a difference of 6 seconds per day, so unlikely to be noticed by most programs. Perhaps the SimCoupe source would show how those are accounted for? The display framerate and cycle counts aren't as tightly linked in SimCoupe, since it can vary the time between frames without affecting the emulation accuracy. I currently use a 20ms periodic timer to give a 50Hz approximation, though the accuracy of that is implementation/OS dependent. The difference does still cause some problems for the frame sync at normal speed. The sound code generates an exact number of samples matching the 50.08Hz rate, but the timer for the frame sync is still working at 50Hz rate. The sound slowly drifts from the emulation until and eventually needs to be corrected, often with a a small audible glitch - something I'll eventually avoid by using the sound buffer for seamless frame sync. Another rather interesting prospect would be that you might be able to literally improve the graphics by plugging in a mayhem accelerator... Neat idea, and maybe as simple as plugging different instruction timings into Si's program. :-) Si
Re: Fully detailed instruction timing breakdown?
Thomas Harte wrote: surely it'd be easiest just to write a routine that shoots out new palette values as quickly as possible It depends how controlled the changes need to be... An unrolled block of OUTI instructions can make 13 changes across a main screen scanline (including both borders). Though that only permits updating of sequential CLUT positions. There is 8T of additional padding needed to keep each scanline aligned, which could allow B to be set to a specific starting offset to update - perhaps even to zero, keeping the final 3 entries constant. For more control, a repeated block of LD B,n ; OUTI would allow updates to any 9 CLUT entries per scanline. It gives 4 changes during the right+left border area, then changes after every 6 columns on the main screen. The last method would probably be easier to create suitable screens for, but if the first one is an option it would give more colours to use. Perhaps LCD could advise on that! Si
Re: Fully detailed instruction timing breakdown?
Andrew Collier wrote: That would mean there should be 384*312=119808 t-states between frame interrupts, but according to that article, if you measure the number of instructions executed during a frame, then even with the screen off it turns out to be slightly fewer than expected. I'd be interested to see how the article measured a difference, as I've only ever seen the official 119808 value myself. Is issue 2 available anywhere? The difference could be an error in the expected timing values, due to mis-alignment with T3. Instruction timings are affected by the cycle alignment left after the previous instruction completed. That's what prevents a definitive list of SAM instruction timings, even when you're only considering the simple border case (same as with screen off). Even a simple NOP in the border area can have 4 different timings, depending on what comes before it: scf; 4T nop; 4T (normal) ld (hl),a ; 7T nop; 5T! inc hl; 6T nop; 6T! ret nz; 5T (assume condition not met) nop; 7T! I picked 1-byte instructions with timings of 4-7T, which leaves a different alignment for the following instruction. That results in a different amount of contention delay for the NOP opcode fetch. In most of these cases the old-style rounding up to the next multiple of 4 still gives the same timings. Instructions that are a multiple of 4T will mask the effects, but it's easy to create problems using a sequences of non-4T multiples: ret nz; 5T inc hl; 9T! ret nz; 7T! ret nz; 8T ret nz; 8T Repeated instructions usually sync with T3 to settle on a consistent (rounded) timing value, as seen in last two instructions. All that fun using just 1-byte instructions! Si
Re: Fully detailed instruction timing breakdown?
LCD wrote: But just a idea: Using Stack Pointer (PUSH) to write in CLUT memory area would be faster than LD Command, right? It certainly would be if SAM's palette was memory-mapped. Unfortunately it's only accessible through 16-bit I/O ports, so we're limited to the slow updates of each CLUT register :-( Si
Re: B-DOS hard disk layout?
Earlier I wrote to Thomas Harte: I don't currently own a regular SD card, so I'm not able to try it myself. I'll see if I can pick one up in the next couple of days I managed to acquire a 1GB SD at lunchtime, so I've had a quick go. It uses normal byte ordering like Atom Lite, so you just need a version of SimCoupe that supports the Atom Lite in addition to original Atom. My 1GB card (SanDisk Ultra II) has 198400 sectors. Trinity BDOS reports Card size 3874, Multiplier 7(?) with 1240 records. SimCoupe and SamDisk both also show 1240 records, and it does work fine as expected. I can check in the AL changes if you want to build a new SimCoupe yourself, otherwise it might take a few days to sort out a binary. Si
Re: ANNOUNCE: SAMflate - gzip file decoder
Andrew Collier wrote: - an implementation of the inflate decompression algorithm from RFC1951, as used by gzip and other compatible utilities. Very nice! Can it be fed straight gzip file data, or does it need the file header stripping from it first? I think I usually pass everything to zlib's inflate, but it may well detect and skip it. Si
Re: SAM Revival issue 22 out now!
Thomas Harte wrote: but is there any solution yet for an entirely solid state Sam? I have an Atom [Lite] card in the drive 2 slot, and use Edwin's modified ROM to boot directly from it. As a bonus, you can use the CF card with SimCoupe on your desktop machine to share all the same programs and data (well, once I've done a release with Lite support!). It's sometimes still be handy to have drive 1 as a working floppy, though not essential if you have access to a desktop PC for disk imaging. I'll see if I've got a spare SAM drive kicking around, as I rarely have 2 fitted anymore. Otherwise Colin can probably help with repair or replacement. Si
Re: interrupts
David Brant wrote: I'm using mode 2 interrupts when I use sim coupe's debugger I get the normal frame interrupt and then a interrupt at line 0 point 52 (real line not SAM coupe line) anyone know whats producing it? It still sounds most likely to be a re-triggered interrupt, even if the status port is FF by the time you check it. Is your interrupt handler fairly short? (close to the 128 cycles the interrupt is active for) If you can e-mail me a test disk image I'll be happy to take a look. Si
Re: New projects Byte-Back 2009
Thomas Harte wrote: is anybody able to loan copies of Prince of Persia, Lemmings, Defender and anything else particularly worth showing? I'm planning to go to the show too, so I should be able to bring any software (or even extra hardware) you need. I've got a SAM In A Can too, with Quazar Surround, SID interface and Atom Lite , if that'd complement a traditional SAM machine on show? Si
Re: Grabbing floppy images
Thomas Harte wrote: Although I'm aware that my USB drive may be hard coded somehow not to support anything other than the PC layout That's pretty much it I'm afraid! USB floppy drives are seen as simple block devices, and the linear-CHS mapping is done inside the unit. I believe DD disks will always be treated as 9-sector 720K (and HD as 18-sector 1.44M), so be missing the 10th sector of each SAM track. I have heard rumours of USB drives with an unofficial way to change the geometry mapping in the drive, but I've yet to find one myself. Until someone creates something like a USB CatWeasel, you'll be unable to access 10-sector disks on a Mac. Even if I can't image original disks, is there any way I could use this drive for some sort of data transfer? You'd be much better off with an Atom Lite board in the drive 2 slot, so you can share a Compact Flash card between SAM and SimCoupe. It's faster, easier and more reliable than dealing with floppies. Edwin can provide them if you're interested. The USB drive situation could be improved, with specially crafted disks that lock out the 10th sector on each track. SimCoupe could assist by returning matching dummy contents for the inaccessible directory and data sectors. You still wouldn't be able to use existing 10-sector SAM disks, but 90% of the space would be usable on new ones. Si
